Secure Erase как раз должен стереть все блоки страниц nand-памяти...в этом и вся соль...

Должен кому?
Он должен обеспечить, чтобы после него через интерфейс диска данные извлечь было нельзя. Он это обеспечивает - с чистой таблицей LBA при запросе любых данных диск будет возвращать нули, т.к. они не отображены во флеш. И нет никакого способа стандартными командами заставить его возвращать данные из флеша, когда отображение в таблицах отсутствует нет. При чтении - "нули", при записи - "стирание и запись". Так что "секьюрность" по спецификации обеспечена, не подкопаешься. Зато - очень быстро, всего лишь таблицу очистить, а не весь диск.

А то, что физически в лаборатории данные считать с чипов можно, подключив их к другому контроллеру - это дело десятое, к делу не относится и спецификацией ATA не описывается..

Физически же заставить SSD стереть все из флеша достаточно сложно.. У него же может быть резерв (и очень часто бывает), и какие данные там отображены даже при полностью заполненном случайными байтами накопителе (если потратить время и забить его ими), неясно.. может, как раз самые ценные.

Mosga То есть вы хотите сказать что во флешь запись в процессе secure erase не производится?...o_O при том то перезаписать весь накопитель дело не такое долгое... В чем суть операции тогда? Скорость "удаления" информации? С ссд даже восстановление данных весьма сомнительная процедура т.к. ITGC и TRIM уничтожают все что было удалено даже на уровне файловой системы...

Добавлено спустя 51 секунду:

Так резервные блоки должны всегда быть чисты...это суть резерва - подсовывать чистые (стертые) блоки для быстрой записи...

Обычно нет. Очищается только таблица.

Десятки минут, а Secure Erase - несколько секунд на большинстве накопителей.

TRIM ничего не уничтожает. Он делает ровно то же - очищает запись в LBA и помечает кусок флеша как "не используемый", при попытке чтения с этих блоков накопитель увидит, что во флеш физического отображения нет и вернет нули. А когда-нибудь, когда припрет записать новые данные во флеш, он реально очистит один из этих кусков и запишет новые данные. А до тех пор что после secure erase (который по сути - глобальный TRIM), что после TRIM там хранятся старые данные. Просто логически их уже не достать, логически они "мертвы".

Ничего подобного. Суть резерва - иметь гаратнированные "блоки", которые можно (по необходимости) стереть и записать новые данные.
Стирание NAND идет большими блоками, скажем, по 512 Kb. Поэтому если на заполненном накопителе стереть много мелких файлов и даже выполнить для них всех TRIM, реально ни одного действительно свободного NAND-чипа может не появиться - т.к. все блоки частично "загажены". А логически места может быть много - а куда, спрашивается, их накопителю записывать, если перед записью нужно стереть, а стереть ничего нельзя, во всех 512 Kb-блоках есть данные? Будет очень неприятная операция, он должен будет собирать кусочки данных из разных чипов, высвобождать цельные блоки, очищать их и туда класть эти старые данные, теперь плотно упакованные вместе и новые данные, которые нужно было запускать. Скорость записи падает ниже плинтуса, износ флеша подскакивает до небес и другие прелести.

Вот тут наличие резервных блоков и спасает. Их всегда можно очистить и записать. И чем больше резерва, тем быстрее запись и тем меньше износ.

А ITGC это по сути то же самое перетасовывание мелких кусочков в большие блоки, чтобы освобождать полные блоки NAND для последующих стираний при необходимости (будут ли они стираться сейчас или потом - вообще не важно, главное возможность такого стирания). ITGC в отсутствии резерва изнашивает диск точно так же, как и та же работа перед записью, но зато работает заранее, а не в момент записи, и накопители, которые ее умеют, сохраняют (или быстро в фоне восстанавливают) полную скорость записи даже после заполнения накопителя. А которые не умеют, просто вынуждены делать это перед записью, с тормозами.

Но лучше, конечно, больше резерва. Тогда есть шанс, используя этот резерв, дождаться, пока пользователь сотрет или перезапишет эти ошметки и не придется собирать их по кусочкам, изнашивая флеш.

Да нет что-то не сходится....Трим конечно сам по себе данные не уничтожает, он сообщает контроллеру накопителя данные каких LBA блоков уже не нужны ОС, и тогда, достаточно быстро, GC подчистит весь этот мусор...то есть реально удалит данные, переместив часть нужных данных в блоках в другой блок (объединив эти данные с другими данными сформировав таким образом максимально полно записанный блок страниц), а исходные ячейки контроллер сотрет...и добавит к остальным чистым блокам...


Только вот такая запись будет очень долгой. а суть GC - подготовить чистые блоки для быстрой записи, то есть стереть их заранее...
Наоборот! Очищенные GC блоки и добавляются к резерву...формируя так называемый over-provisioning...
Как раз таки они стираются сразу...потму что чем больше свободных блоков страниц - тем в большей степени накопитель готов для быстрой записи максимального количества данных...

Резерв есть у всех накопителей...


Сейчас - все умеют...и GC и ITGC...

Только "реальное удаление" не гарантируется (и не требуется). То, что при чтении блоков из под файла сразу возвращаются нули после операции TRIM - всего лишь обработка таблицы отображения, в которой эти LBA-блоки временно никуда не ссылаются.

Да нет, все вполне быстро стирается. Перемещать долго. Но вообще это зависит от реализации.
Предварительное стирание в фоне, не мешающее чтению и записи - вещь интересная, но это еще только прикидывают, как хорошо сделать (например, тут https://www.usenix.org/legacy/events/fast12/tech/full_papers/Wu.pdf).

От фонового GC - разумеется, но я писал про вынужденный GC, когда блоков из резерва нет.

Но далеко не у всех, особенно без ITGC его хватит.. И придется делать GC перед записью, и будет печалька. Что и видно на примере некоторых накопителей.

Но, в общем, это совсем оффтопик - производители заботятся о скорости и износе, а не о гарантированности стирания. Никакой Secure Erase или TRIM не дает гарантии стирания данных с флеша даже через долгое время, поэтому уничтожать чип физически - вполне себе вариант..

Asus Repair Kit™ наше всё!