Судя по всему уже никак. Во-первых, они изначально производились для OEM и Enterprise, где приняты свои методы обновления, а во-вторых они вообще end-of-life.
Я как-то пристрастился для проверок f3write/f3read использовать. Они, правда, пишут данные в файлы, то есть требуют наличия ФС. И не могут проверить места, занятые структурами ФС. Зато процесс можно прерывать и возобновлять, что удобно, когда не можешь держать комп включенным круглосуточно.
Which OS platforms does Samsung Magician work on?
Samsung Magician 8.3 is compatible with the following operating systems: Windows 10 (32-bit/64-bit), macOS High Sierra 10.13, and Android 5.1 and above. For Windows 8.1 and lower, please use Magician 7.3. The Linux operating system is not supported. Internal SSDs are not supported on macOS or Andriod.
Чётко сказано «The Linux operating system is not supported.» Причём на macOS тоже всё плохо - только переносимые устройства.
Понял. В наше время обновления используются не только и не столько для исправления ошибок, а для вещей, которые со временем существенно ухудшают мой, как они говорят, user experience. Поэтому я обновляюсь только в безвыходных ситуациях.
Держите в курсе, если что-то пойдёт не совсем как ожидалось.
Спутался, подразумевал f3brew, которая в каждый блок пишет последовательность, генерируемую от смещения блока. А потом читает и проверяет. И её можно указть, что только читать или только писать и диапазон, но она не ведёт лог записаных/прочитаных блоков и не умеет продолжать.
Наверное, можно написать скрипт, который через strace или /proc/PID/fdinfo/ отслеживает сколько уже записано/прочитано, логгирует, перезапускает... но как-то сложновато.
f3probe — это так, непонятно что, и все блоки не проверит и в споре на Алике не поможет :)
А что скажете про Kingston FURY Renegade? Я случайно скроллил и натолкнулся на него. TBW почти в два раза больше, чем у Самсунга, цена такая же, как у 990 Pro, радиатор в комплекте, гарантия в ДНС 5 лет (против 1 года Самсунга).
Как-будто бы топ-писечка, нет?
Я, конешно, Кингстону не особо доверяю, но за 5 лет гарантии это не моя проблема.
p.s. да, я знаю, что у Самсунга тоже пять лет, но не в России.
Тут уже где-то их упоминали. У меня два таких в ЛВМ-рейде, 4000 часов, полёт нормальный. Обычно греются не сильно, но при очень интенсивном использованиии до 70° догнать могут. Но мои с прошивкой EIFK31.7, а была ещё какая-то серия с багованной прошивкой бо́льшего номера, которая дико грелась. В теории, наверно, можно нагуглить даты её выпуска, чтобы при покупке посмотреть на упаковке.
а, ещё они (видимо, из-за старого стандарта NVME 1.4) не понимают каких-то команд, из-за чего постепенно растёт счётчик ошибок. ничему не мешает, но кого-то может напрячь.
можно написать скрипт, который через strace или /proc/PID/fdinfo/ отслеживает сколько уже записано/прочитано, логгирует, перезапускает… но как-то сложновато.
Запускаешь f3brew с указанием –start-at= и –end-at=, выбрав такой кусок работы, чтобы f3brew выполнялся не долго, но и не особо быстро. Затем организуешь цикл от 0 до последнего блока с шагом в выбранный кусок работы. Перед запуском f3brew для конкретного смещения проверяешь, есть ли stamp-файл. Если есть, пропускаешь кусок. Если файла нет, то запускаешь f3brew, и при его успешном завершении создаёшь очередной stamp-файл. Имена stamp-файлов — просто начальные смещения в блоках.
Ну, не весь, а половина. Сначала нужно таким образом записать весь накопитель, потом прочитать. Иначе можно не выявить «перекрёстную» запись. Следовательно, скрипт должен по stamp-файлу определять где его прервали — на записи или на чтении.
Следовательно, скрипт должен по stamp-файлу определять где его прервали — на записи или на чтении.
Ну называть файлы не 0, 4096, 8192 и так далее, а write0, read0, write4096, read4096, write8192, read8192 и так далее. Или просто забить на усложнение скрипта и сделать два отдельных, для записи и для чтения. И не нужно пытаться автоматизировать каждую мелочь. Некоторые операции проще будет сделать руками.
Хотя, конечно, если проверка накопителей это часть твоей рутины, то можно и заморочиться. Скрипты там, патчи на сами утилиты f3.
Там есть EIFK31.6 — памяти Micron 176L, которые сейчас не найти, EIFK31.7 — Toshiba BiCS5 112L и EIFK51.2, что, вроде как, Kioxia BiCS5 112L, но непонятно, так как Toshiba Memory переименована в Kioxia в 2019 году, а эти модели SSD явно позже.
И самое непонятное, чем эти Fury отличаются от Kingston KC3000, кроме цены?
Ну без этого то никуда, там f3brew не останавливается при обшиках записи, просто выводит «warn», а смысла запускать read-тест, если запись не получилась нет.
забить на усложнение скрипта
Всё усложнение — определение прошлали запись на весь накопитель или нет. Делать это автоматически как раз не мелочь, а экономия времени, на что и нацелена автоматизация. Определять вручную что сейчас нужно запускать read- или write- скрипт лишние траты времени.
А так, с f3brew, ещё из интерестного, что если разом write+read-тест, то он делает dev_reset() (вроде как usb-reset). Ну и имеет код поиска устройства после reset, так как оно переименовалось. И вот непонятно, имеет ли это смысл, что для флешек, что для SSD. Или вобще сходить с ума по полной и после write-теста делать отключение питания...
У меня ничего не ломается, живут по 10 лет и больше, никаких тенденций к ухудшению пока не замечалось.
Не надо покупать на маркетплейсах и не надо покупать чрезмерно дешёвые модели и всё будет норм. Ну и не надо по ним молотком бить, на всякий случай тоже уточню.
тошиба и wd 1ТБ про wd не уверен в его вине, ибо мог блок питания мог свою лепту внести. Информацию смог там и там стянуть, на работе ssd портились всё терялась без возвратно. Дома ssd использую бекапы фильмы на старые hdd.