— Гость (09/03/2014 02:39)   
Большинство ответов на ваши вопросы содержатся в старых топиках, рекомендую их все прочитать:

1. Угроза восстановления перезаписанных данных с флешек и SSD. Есть ли аналогии с МСМ для винчестеров?^[link1]
2. Надёжное удаление данных с SSD-накопителей^[link2]
3. Использование SSD при шифровании^[link3]
4. Полное дисковое шифрование SSD^[link4]
5. Так все же SSD диск криптовать полностью или нет?^[link5]
6. Посоветуйте надежные microSD!^[link6]
7. /comment39601^[link7]
8. /comment72188^[link8] (HPA)
9. SSD не дружит^[link9] с отрицаниемым шифрованием, если что.

Чтобы очистить основную область — да. Это не гарантирует зачистки так называемых резервных блоков / HPA. В общем случае, ничего не гарантирует их зачистку, поэтому 100% гарантии вам никто не даст, если только вы сами с паяльником и спецаппаратурой туда не залезете и не проверите, как работает ваш проприетарный насквозь микроконтроллер. Считаете ли вы для себя этот риск (незачищенные резервные блоки) приемлемым — решать вам.

В качестве полумеры можно записать всюду нули, а потом сделать sync. Поидее, это должно затереть дисковое пространство, за исключением, разве что, того небольшого объёма данных, которое попадёт в резервные блоки / HPA. Если это не устраивает, покупайте новый носитель. Вообще говоря, намного проще сразу всё шифровать, что пишется на диск, чем потом морочить себе голову зачисткой старых данных.

Кстати, этот^[link10] топик тоже рекомендую прочитать.

— unknown (09/03/2014 16:51)   

Если записывать нули непосредственно на носитель, то есть вероятность, что в SSD используется аппаратное архивирование и нули очень хорошо пожмутся, заполнив крайне мало от физически находящегося там полного размера. При этом, контроллер может показать, что всё занулено до отказа, а оставшуюся недоступную для прямого чтения часть использовать под резервные блоки.

Поскольку любой носитель всё равно лучше затирать (псевдо)рэндомом (шифрованные нули — это тоже псевдорэндом), то лучше заполнить носитель полностью рэндомом, затем сделать sync, а затем ещё раз пройтись рэндомом и сделать sync. Это с некоторой веротностью позволит обойти сохранение контроллером флэш-носителя резервных блоков. Хотя, не все алгоритмы выделения блоков для резервирования могут быть преодолены таким способом.

Так что, задача мало отличается от недавно обсуждаемой темы^[link11], разве что использованием двух проходов, чередуемых sync.

— Гость (10/03/2014 04:52)   

А оно действительно существует, или это всего-лишь предположение? И есть ли такое аппаратное архивирование также в флэшках, SD-картах?


А три прохода не будет лучше, чем два? Вдруг 2 прохода не повлияют на какие-то резервные блоки, а три повлияют. Такое может быть?

— Гость (10/03/2014 06:09)   

Я как-то давно встречал случай, когда карта CompactFlash^[link12] не писала нули, т.е., нули как-то отмечались, но пропускались, за счет чего карта работала быстрее. И в первых SSD, не поддерживающих TRIM, использовалось обнаружение нулевых секторов для очистки ячеек флеша. Однако, именно про сжатие не слышал.

Насколько я знаю, когда TRIM стал поддерживаться, детектить и сжимать нули (это касалось CompactFlash-карточкек и первого поколения SSD, очень древних; SD-карточек это не касается) стало бессмысленно. Сейчас все полагаются на TRIM, а на поддержку неTRIM'овых девайсов операционные системы забили. И именно поэтому сейчас без TRIM'а ресурс мизерный.

— Гость (10/03/2014 07:25)   
На SSD, насколько я знаю, для стирания данных вообще не нужна перезапись: операция erase для флеша — это отдельная, третья операция. Её можно инициировать либо TRIM'ом (частичное стирание, узнать о завершении нельзя), либо командой SECURE ERASE (полное стирание, синхронное); перезапись же блока может как вызывать стирание, так и не вызывать, поскольку у контроллера сложные алгоритмы оптимизации износа: он может записать в новый свободный блок, а старый поставить в очередь.


Да, согласен, встречал такое. Если перезаписывать, то только рандомом.


Это минимально достаточное количество, чтобы заставить контроллер стереть резервные блоки. Если перезаписать только 1 раз, данные могут остаться в HPA в резервных блоках, которых бывает до 20-30% от емкости накопителя. Нужно перезаписать два раза — это дает надежду, что резервные блоки перезапишутся, так как 100% резерва не имеет ни один накопитель. Можно сделать SECURE ERASE, если накопитель его поддерживает (а я где-то слышал что есть накопители, которые игнорируют эту команду и ничего не стирают).

Как сделать гарантированное частичное старание данных с SSD — вообще не знаю. По-моему — никак: либо полное, либо полагаться на TRIM.

— Гость (02/03/2015 20:58)   

Это как?

И у меня такой чайниковский вопрос. Если я создаю на ЧАСТИ SSD винта раздел (дальше его шифрую или записываю файлы, а затем удаляю и собираюсь ПОВЕРХ них записать другие и т.п.), то создаваться/удаляться этот логический раздел будет физически "на одном и том же месте" (в тех же кластерах памяти) или нет? Я понимаю, что для надежности нужно не пользоваться SSD для секретов, а на крайний случай затирать ВЕСЬ диск, но все-таки диск большой, а критических данных на 1% и мне важно знать "размажутся" эти 1% по диску или нет и можно ли будет их как-нибудь целиком прибить?
(у меня тот случай, что я не могу создать файловый криптоконтейнер на открытой ФС)

— unknown (02/03/2015 21:13)   

Вот именно, что нет — все ячейки SSD пишутся по кругу. Кроме того, там ничего не удаляется, если не используется TRIM и то не факт, что там происходит внутри, какие коды избыточности используются.

— Гость (03/03/2015 06:50)   

Если TRIM выключен, отрицаемость будет, но ценой быстрого износа диска, появления bad-блоков и т.д. Если TRIM включён, износ уменьшится, но пропадёт отрицаемость.