Комментарии 35
Не хватает раздела с Linux, а именно про разные файловые системы. Где-то это реализовано по таймеру fstrim, где-то как sync/async discard. Ну и у хостеров, например, как и для чего используется TRIM внутри гостевых ОС (при thin provisioning сообщить виртуализации storage что это место свободно, при отсутствии trim занятое место будет расти до победного)
HDD не так просты. Shingled HDD имеют буферную зону, куда пишут новый файл сначала, а потом при простое переносят его в основную. Копия в буферной зоне при этом физически не стирается конечно. И сомневаюсь, что всякие secure delete могут её стереть.
TRIM таким HDD тоже нужен, потому что они постоянно в себе что-то шебуршат, реорганизуют и упаковывают. Так что пусть хотя бы не шебуршит заведомым мусором.
После прочтения вам может стать интересно, действительно ли ваш блокиратор записи умеет блокировать не только запись, но и команду TRIM, это можно проверить. Опять же, на диске, на котором нет никаких важных данных.
Сначала убедитесь, что TRIM вообще работает, сначала выполнив предыдущую последовательность. Затем мы проверим поведение через блокиратор. Повторите шаги записи сигнатуры и проверки её наличия из первого сценария, используя новую строку.
Сначала было все нормально, потом из неоткуда появился какой-то блокиратор.
Так и пишите что это перевод.
Кажется там примерно вот такой перевод: https://habr.com/ru/articles/967428/
Я с начала текста заподозрил неладное, он и по смыслу странный и фразы там какие-то не человеческие, типа
При записи система не прячет файлы — она сохраняет их координаты в специальной таблице.
Надо же, а я всегда думал, что смысл записи на жесткий - спрятать файлы.
Ребят, если это реально нейросеть - остановитесь, пожалуйста. Ну зачем?
А меня стригерило слово "твердотелка". Цитируя упомянутую вами статью, после которой действительно невозможно развидеть слоп:
Живые копирайтеры обычно не придумывают слова, а если и придумывают — то делают это осознанно в формате "назовем этот эффект Х". <...> ЛЛМ-ка комбинирует токены, у нее нет понимания что придумывать новое нехорошо, для нее придумывание предложений близко к придумыванию слов.
Кажется там примерно вот такой перевод: https://habr.com/ru/articles/967428/
Так автор как бы намекает :)
О, многие SATA-USB адаптеры с поддержкой защиты от записи вообще не блокируют никакие команды, а тупо выставляют бит "Read Only" для операционки. При этом команды записи как SCSI, так и ATA Pass Through успешно проходят
Статья интересная, но хотелось бы узнать в дополнение - как работает утилита chkdsk на SSD?
Ведь если на контроллер SSD влиять невозможно, как я понимаю, может возникнуть такая ситуация, что он захочет записать данные в раннее помеченный ОС битый сектор SSD?
Помеченный чем и как? У NTFS есть своя таблица битых блоков.
ОС вроде нынче не помечает секторы как битые, а если и пытается, то всеравно все управление резервными блоками и их перераспределение за контроллером ssd/hdd
как я понимаю, может возникнуть такая ситуация, что он захочет записать данные в раннее помеченный ОС битый сектор SSD?
нет, не может. ОС вообще не имеет доступа к raw-секторам. Она просто пишет в "виртуальные" сектора, а трансляцией виртуальные-реальные занимается контроллер и он постоянно эту таблицу модифицирует для выравнивания износа или для CoW, да. В то же время контроллер понятия не имеет, что именно там ОС пишет, что не пишет, куда она пишет, он оперирует просто командами "считать-записать", это касается и данных и таблицы разделов.
А TRIM это как раз способ сказать контроллеру ссд "вот эти данные ОС не нужны, их можно стирать". Если накопитель не триммить, то он не будет знать, какие данные уже удалены на уровне ОС, и будет пытаться их сохранять (для него все данные однозначны), тратя ресурс ячеек и уменьшая скорость (потому что для скорости надо иметь запас в 20% емкости чтобы CoW был быстрым), пока ОС не перепишет этот виртуальный сектор новыми данными.
На уровнь ОС битые сектора не попадают вообще (или попадают когда их количество выходит за пределы блоков автокоррекции), их можно получить только через SMART, потому что у ссд есть запас памяти на случай выхода из строя ячеек (ну, точнее, блоков). Причем контроллер умеет определять износ ячеек, и еще до потери данных помечает ячейку как исчерпавшую свой ресурс и записывает ее адрес в специальную таблицу у себя в памяти, чтобы не записывать туда данные.
На уровень ОС битые сектора не попадают вообще
Но ведь тем не менее для SSD chkdsk не только не отключен, но и как раз, как я понимаю, логически помечает битые сектора (https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chkdsk?tabs=ssd%2Cevent-viewer):
How chkdsk performs on different media (SSD) - Marking clusters bad is logical, not physical remapping.
Например если логически утилита пометила битый сектор, то на уровне контроллера он будет считаться просто "не пустым" и, следовательно, не подверженным TRIM? А, например, если будет выполнено быстрое форматирование диска - то данные о том что сектор битый удалятся или нет... В общем с диагностикой и исправлением ошибок на SSD сейчас больше вопросов чем ответов, как мне кажется)
Del
Вопрос к знатокам. Имеется SSD HP (Samsung) SLC, который не поддерживает TRIM и, тем более, Secure Erase и, тем более, Sanitize.
Каким паттерном можно заполнить диск, чтобы он был, условно говоря, в "заводском" состоянии - 0x00 или 0xFF ? Я заполнял 0xFF, но теперь не уверен, хранятся ли данные в NAND в прямом или инверсном виде.
PS: только что пришло в голову сделать Sanitize какому-нибудь более свежему MLC диску, записать один сектор 512 байт и потом считать 16 KB...
(добавлено) нули отдаёт. Перемудрил )))
Нельзя писать статику, а то контроллер дедуплицировать может. /dev/random довольно медленные, но сойдет. Иначе badblocks в режиме записи как пример, которая рандом из сида генерит.
Можно викторией сделать низкоуровневый тест записи выбирая запись номера LBA. Заодно получается статистика по времени доступа к секторам и график скорости. Если взять видавший жизнь SSD и прогнать такой тест, то получается график-расчёска с порой немалыми просадками по скорости, а если прогнать второй раз, то график становится очень даже ровненький.
Не факт что виктория "виновата" в таком поведении. Если взять давно не включавшийся ssd, контроллер будет пытаться перезаписать (освежить) все ячейки, так как вообще говоря сохранность данных в выключенном состоянии гарантируется лишь сколько-то месяцев, и чем дольше он без питания, тем больше риск условного bit flip
Я к тому что викторией можно "освежить" диск, полностью очистив его в профилактических целях. Так-то понятно что блок в виктории мало общего имеет с блоками, с которыми контроллер SSD работает.
А как он узнает, что давно не включался? В нем разве есть часы?
Тут видимо от фантазии разработчика зависит, не буду врать что он какие-то уровни напряженности ячеек измеряет или что-то такое. Как минимум некоторые серверные ssd пишут лог с температурой с таймстемпами. Время наработки и количество вкл-выкл же все пишут
На каком типе SSD и какой версии Виктории это сработало?
Пробовал версию 5.37 примерно на десятке разных SSD, но эффекта восстановления при тесте поверхности - не обнаружил.
Victoria 5.37. Samsung 980 500Gb, SATA.
У меня лучше работает другой способ - удаляю все разделы с SSD (если данные нужны - делаю копию на другой диск)
Создаю разделы заново, или восстанавливаю с копии.
Скорость снова становится как у нового.
Каким паттерном можно заполнить диск, чтобы он был, условно говоря, в "заводском" состоянии - 0x00 или 0xFF ? Я заполнял 0xFF, но теперь не уверен, хранятся ли данные в NAND в прямом или инверсном виде.
Кажется, никаким. Насколько я понимаю, там почти везде щас есть слой шифрования, и secure erase часто заключается в генерации нового ключа шифрования, после чего все данные теряют смысл.
Но вообще изначально шифрование там для того, чтобы в данных не было длинных последовательности 0/1, а было бы равномерное распределение битов, чтобы износ был равномерным. Поэтому любой паттерн запиши, все одно будет плюс-минус случайные данные на низком уровне
Что такое "неверные данные"?
Что вы думаете по этому поводу?
Думаю, што не стоит называть SSD диском. Незачем путать новые поколения людей.
Что происходит с удалёнными файлами: разбираем алгоритм TRIM и его нюансы