Подготовка к работе б/у ssd
minisata ssd должен быть использован для установки на него debian 7 x64 с encrypted lvm. lvm будет настроен с использованием стандартных функций установщика.
Дело в том, что данный ssd уже использовался в качестве системного с той же ОС, но без lvm и без dm-crypt, т.е. был самым простым стандартным образом рамечен установщиком.
Вопрос состоит в том, как правильно приготовить данный ssd к использованию в качестве системного с encrypted lvm, с учетом следующего таких особенностей ssd, как чувствительность к многократной перезаписи, особенностям хранения данных.
Достаточно ли будет просто направить на устройство поток нулей, либо urandom.
Должна ли команда
быть модифицирована в случае с SSD?
Скажем, достаточно ли пройтись по диску командой:
Избыточна ли одна такая команда, либо наоборот недостаточна? А может, будет достаточно только нулей?
Спасибо.
Чтобы очистить основную область — да. Это не гарантирует зачистки так называемых резервных блоков / HPA. В общем случае, ничего не гарантирует их зачистку, поэтому 100% гарантии вам никто не даст, если только вы сами с паяльником и спецаппаратурой туда не залезете и не проверите, как работает ваш проприетарный насквозь микроконтроллер. Считаете ли вы для себя этот риск (незачищенные резервные блоки) приемлемым — решать вам.
В качестве полумеры можно записать всюду нули, а потом сделать sync. Поидее, это должно затереть дисковое пространство, за исключением, разве что, того небольшого объёма данных, которое попадёт в резервные блоки / HPA. Если это не устраивает, покупайте новый носитель. Вообще говоря, намного проще сразу всё шифровать, что пишется на диск, чем потом морочить себе голову зачисткой старых данных.
Кстати, этот топик тоже рекомендую прочитать.
комментариев: 9796 документов: 488 редакций: 5664
Если записывать нули непосредственно на носитель, то есть вероятность, что в SSD используется аппаратное архивирование и нули очень хорошо пожмутся, заполнив крайне мало от физически находящегося там полного размера. При этом, контроллер может показать, что всё занулено до отказа, а оставшуюся недоступную для прямого чтения часть использовать под резервные блоки.
Поскольку любой носитель всё равно лучше затирать (псевдо)рэндомом (шифрованные нули — это тоже псевдорэндом), то лучше заполнить носитель полностью рэндомом, затем сделать sync, а затем ещё раз пройтись рэндомом и сделать sync. Это с некоторой веротностью позволит обойти сохранение контроллером флэш-носителя резервных блоков. Хотя, не все алгоритмы выделения блоков для резервирования могут быть преодолены таким способом.
Так что, задача мало отличается от недавно обсуждаемой темы, разве что использованием двух проходов, чередуемых sync.
А оно действительно существует, или это всего-лишь предположение? И есть ли такое аппаратное архивирование также в флэшках, SD-картах?
А три прохода не будет лучше, чем два? Вдруг 2 прохода не повлияют на какие-то резервные блоки, а три повлияют. Такое может быть?
Я как-то давно встречал случай, когда карта CompactFlash не писала нули, т.е., нули как-то отмечались, но пропускались, за счет чего карта работала быстрее. И в первых SSD, не поддерживающих TRIM, использовалось обнаружение нулевых секторов для очистки ячеек флеша. Однако, именно про сжатие не слышал.
Насколько я знаю, когда TRIM стал поддерживаться, детектить и сжимать нули (это касалось CompactFlash-карточкек и первого поколения SSD, очень древних; SD-карточек это не касается) стало бессмысленно. Сейчас все полагаются на TRIM, а на поддержку неTRIM'овых девайсов операционные системы забили. И именно поэтому сейчас без TRIM'а ресурс мизерный.
Да, согласен, встречал такое. Если перезаписывать, то только рандомом.
Это минимально достаточное количество, чтобы заставить контроллер стереть резервные блоки. Если перезаписать только 1 раз, данные могут остаться в HPA в резервных блоках, которых бывает до 20-30% от емкости накопителя. Нужно перезаписать два раза — это дает надежду, что резервные блоки перезапишутся, так как 100% резерва не имеет ни один накопитель. Можно сделать SECURE ERASE, если накопитель его поддерживает (а я где-то слышал что есть накопители, которые игнорируют эту команду и ничего не стирают).
Как сделать гарантированное частичное старание данных с SSD — вообще не знаю. По-моему — никак: либо полное, либо полагаться на TRIM.
Это как?
И у меня такой чайниковский вопрос. Если я создаю на ЧАСТИ SSD винта раздел (дальше его шифрую или записываю файлы, а затем удаляю и собираюсь ПОВЕРХ них записать другие и т.п.), то создаваться/удаляться этот логический раздел будет физически "на одном и том же месте" (в тех же кластерах памяти) или нет? Я понимаю, что для надежности нужно не пользоваться SSD для секретов, а на крайний случай затирать ВЕСЬ диск, но все-таки диск большой, а критических данных на 1% и мне важно знать "размажутся" эти 1% по диску или нет и можно ли будет их как-нибудь целиком прибить?
(у меня тот случай, что я не могу создать файловый криптоконтейнер на открытой ФС)
комментариев: 9796 документов: 488 редакций: 5664
Вот именно, что нет — все ячейки SSD пишутся по кругу. Кроме того, там ничего не удаляется, если не используется TRIM и то не факт, что там происходит внутри, какие коды избыточности используются.
Если TRIM выключен, отрицаемость будет, но ценой быстрого износа диска, появления bad-блоков и т.д. Если TRIM включён, износ уменьшится, но пропадёт отрицаемость.