LINUX.ORG.RU

Быстрая очистка диска от предыдущих структур и файловых систем

 


0

1

Какая есть простая команда для уничтожения всех остатков любых видов разметки и файловых систем на диске перед началом новых разметки и форматирования? Знаю, что можно включать аппаратное шифрование ни дисках и просто сбрасывать ключ. Этот вариант не подходит, да и оверкил.

Чтобы была понятна мотивация вопроса, придётся расписать пример из жизни. USB-Диск был отформатирован в linux под ext4 (gpt), на нём были сохранены файлы. Затем он был подключен к винде, отформатирован в ntfs через diskpart (clean, convert gpt, create part primary, format quick). Долго использовался под ntfs. Затем снова был подключен к linux и размечен в gdisk. Но не успел я ещё запустить mkfs, как он смонтировался с ФС ext4 (-с той ФС, которая была на нём еще до ntfs). И я даже обнаружил там целые читаемые файлы.

Т.к. это был SSD диск, я не стал форматировать заново и учитывая, что trim через usb не работал, для профилактики вбил blkdiscard. Команда сработала только через sata. Это моментально очистило все блоки, пометив не используемыми и соответственно никакие конкретные адреса затирать уже не надо было, чтобы разрушить имевшиеся там ФС и разметки (а так же файлы). Если я правильно понял, blkdiscard это как fstrim, но вместо отправки конкретного списка удаленных блоков из таблицы файловой системы говорит диску, что ВСЕ блоки можно считать не нужными.

Но этот опыт мне не понравился. Мне бы хотелось избежать любых возможных коллизий из-за остатков ФС и разметки. Ведь есть всякие приколы типа гибридной MBR. В protective MBR записывается том размером 2ТБ даже на дисках в 4тб. И непонятно, может ли пострадать область диска за пределами этих 2ТБ в случае чего. Есть загрузочные диски с iso структурой, где один том перекрывает другой. Да и нежелательные файлы всё таки не хочется внезапно увидеть на давно уже удалённой ФС.

Каждый раз втыкать SSD в sata и вбивать blkdiscard неудобно. А для HDD такой хак вообще недоступен (ну не затирать же его нулями постоянно через DD во всех потенциально содержащих какие-то структуры секторах). -Это тоже неудобно.

PS Скорость записи на ntfs под linux 50мБ/с (под вендой упирается в sata). Это норма?

для SSD blkdiscard. да неудобно, что только через SATA, но зато эффективно.
а что usb-sata конверторы не пропускают trim ??

для HDD

sudo dd if=/dev/urandom of=/dev/sd****

да неудобно, что медленно, но иных вариантов нет, в HDD нет системы быстрой очистки больших блоков памяти :) посему придется записывать в каждый.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)

Быстрой - не существует. Быстрее всего FAT очистить, но данные никуда не пропадают

Скорость записи на ntfs под linux 50мБ/с (под вендой упирается в sata). Это норма?

Да

tiinn ★★★★★
()
Последнее исправление: tiinn (всего исправлений: 1)
Ответ на: комментарий от pfg

а что usb-sata конверторы не пропускают trim ??

Смотря какие. Ugreen обманул и вместо ASM235CM поставил что-то попроще в коробку без полноценного UASP. ASM235CM заявлен был для всех моделей, но теперь он только в той, где Type-c. Это во-первых. А во-вторых, USB 2.0 не может в trim. А он до сих пор во всех андроидах даже середины 23 года выпуска. Ну и некро-ПК никто не отменял.

Вы предлагаете мне писать кашу посекторно от начала до конца? Это же займёт часы. Там в коментах wipefs упомянули. Я про неё знал, но судя по мануалу, она не решает поставленную задачу, верно?

rnduser
() автор топика
Ответ на: комментарий от tiinn

но данные никуда не пропадают

Это я понимаю. Если бы стояла задача уберечь файлы от майора, я бы просто юзал veracrypt или luks. Нет, в данном случае меня волнуют только коллизии/ошибки, которые могут возникать при разметке поверх старых остатков.

rnduser
() автор топика
Ответ на: комментарий от pfg

wipefs удалит достаточно, чтобы нельзя было смонтировать что-либо без запасных суперблоков или в аварийном режиме.

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

anonymous
()
Ответ на: комментарий от rnduser

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

tiinn ★★★★★
()
Последнее исправление: tiinn (всего исправлений: 1)
Ответ на: комментарий от anonymous

DISCARD, потому что оно ничего не удаляет, и на некоторых накопителях данные будут читаться без проблем после этой операции.

Конкретно на моём HP S750 1TB (SMI2259XT) данные убило. Опцию –secure не приняло, вбил просто «blkdiscard -f». Если SSD не выполняет эту команду, тогда дело худо. Потому что тереть его нулями чревато последствиями - ведь будут заняты буквально 100% ячеек и диск не сможет корректно выполнять trim, выравнивание износа и SLC буферизацию (Если я правильно понял). Тогда о чём думают производители, как по их мнению очищать надо-то? Тем более, если аппаратное шифрование не завезли.

rnduser
() автор топика

Если резюмировать. Убиваем ФС через wipefs. А чтобы удалить остатки разметки, пишем через DD нулики примерно в те интервалы адресов, где обычно расположена служебная информация (потерли в начале, в середине, в конце и на всякий случай там, где могли быть границы дополнительных томов). Так получается?

rnduser
() автор топика
Ответ на: комментарий от rnduser

Нет, в данном случае меня волнуют только коллизии/ошибки, которые могут возникать при разметке поверх старых остатков.

С чего бы им возникнуть-то?

Ну да ладно, волнуют так волнуют. Если нуждый скрывать данные от майора задачи нет, то вместо /dev/urandom можно заюзать и /dev/zero.

cat /dev/zero > /dev/sdX
CrX ★★★★★
()

PS Скорость записи на ntfs под linux 50мБ/с (под вендой упирается в sata). Это норма?

Убедись, что монтируется как ntfs3 (не просто ntfs, не ntfs-3g, и т.д.), а лучше явно задавай в команде монтирования: mount -t ntfs3 -o user,rw,noatime,windows_names "/dev/$PARTITION" "$MOUNTPOINT" (ну или в fstab тип как ntfs3 пропиши, не auto, не ntfs, если через него).

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

С чего бы им возникнуть-то?

Так откуда же мне знать :D Я человек простой. Даже не админ в серверной. Ну допустим какой-нибудь андроид увидит ntfs, проигнорировав живую ext4. Или до меня на диске была гибридная мбр. А её какая-нибудь венда прочитает, как обычную даже после diskpart clean. И убьёт какой-нибудь том. Не знаю - просто хотелось понять, что писать в консоль, не включая голову, когда в руки попал диск и его надо разметить.

rnduser
() автор топика
Ответ на: комментарий от rnduser

Ну… «Не должно» (как в том анекдоте). Но вообще, заполнение диска нулями, как сказано выше, решит проблему. Единственный минус — долго — займёт примерно столько же времени, сколько запись соответствующего объёма данных на диск. Если это не напрягает, и главное не включая голову — бери да делай так, не ошибёшься, просто подождать надо будет часок-другой (в зависимости от объёмов и скорости диска). Если ждать всё же напрягает — ну заполни нулями только начало диска, да и всё. Таблицу разделов это прикончит, а что там дальше уже неважно.

CrX ★★★★★
()
Ответ на: комментарий от rnduser

у меня был вопрос аккурат к USB. trim это команда sata-протокола, для работы с блоками стирания ssd, мне почему-то казалось что usb обертка должна быть прозрачна для sata-протокола.

для hdd полное уничтожение данных возможно лишь только при записывании в каждую ячейку данных.
во флеш-памяти есть особенность, стереть (перевести в FF/00 все ячейки блока) можно только большими блоками, это специально сделанная аппаратная особенность.

wipefs, судя по беглому взгляду на man, стирает таблицу разделов и заголовок файловой системы. наполнение фс оставляя нетронутым…

ты точно пропиши, что чистишь: hdd или ssd ибо у них ячейки памяти аппаратно очень отличаются :)

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)

HDD тут только посекторное затирание информации, быстрее только молотком) dd, shred.

SSD с ними помогает hdparm. Операция пару секунд и носитель «обнулен».

С M.2 SSD в помощь nvme-cli. Операция пару секунд и носитель «обнулен».

ЗЫ если используется USB box, то надежда только на контроллер с поддержкой trim.

anonymous
()
Ответ на: комментарий от pfg

ты точно пропиши, что чистишь: hdd или ssd ибо у них ячейки памяти аппаратно очень отличаются :)

Я уже уточнил, что цели уничтожить файлы не стоит в данном случае. Если бы именно это меня интересовало, я бы юзал шифрование. Но свой вопрос я решил. Благодаря ответам я понял ситуацию и тему можно закрывать.

ps: usb пропускает команду trim ТОЛЬКО начиная с usb 3.0 (и то должен быть в ОС соответствующий UASP драйвер). И ТОЛЬКО, если контроллер конвертера поддерживает UASP и trim. Задача выбора конвертера осложняется китайским рандомом. Некоторые контроллеры нестабильны просто (даже на дорогих док станциях орико). Про jmicron гуглится проблема с поддержкой на всяких малинках. Но ASM235CM вроде ок должен быть. И там даже можно вкл/выкл режим сна без перепрошивки - из под софта с гуем. Если коробка умеет uasp+trim и версия usb 3.0 или выше, то trim должен проходить.

С коробками много приколов. Вот процитирую пример:

«Некоторые usb-диски делают обратное преобразование: они объединяют группы секторов по 512 байт в один сектор по 4096 байт. Это позволяет разбивать внешние диски от 2 ТБ до 16 ТБ с помощью MBR. Однако не все внешние диски делают этот перевод. На самом деле у USB есть собственное 32-битное ограничение, поэтому, если вы установите диск объемом более 2 ТБ в корпус, который не выполняет эту трансляцию, вы, вероятно, потеряете доступ к большей части диска. Наиболее распространенным симптомом является то, что диск выглядит по модулю (остаток) своего истинного размера с 2 ТиБ — например, диск 3 ТиБ будет выглядеть как 1 ТиБ. Когда корпус выполняет это преобразование, становится трудно перемещать диск туда и обратно между «переводящим» корпусом и его непосредственным использованием в компьютере, поскольку размер сектора — и, следовательно, размеры начала и конца раздела в секторах — будут меняется при перемещении диска.»

rnduser
() автор топика
Ответ на: комментарий от rnduser

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

Chord ★★★★
()
Ответ на: комментарий от Chord

То, что ты написал в ОП - дичь.

Да проверь сам и убедишься. ext4->ntfs->diskpart clean->gdisk=восстаёт из мертвых ext4 и автомонтируется, как обычно со съёмными дисками.

rnduser
() автор топика
Ответ на: комментарий от CrX

Но вообще, заполнение диска нулями, как сказано выше, решит проблему

А заодно выявит совсем уж убитые бэдблоки при их наличии

nebularia ★★★
()
Последнее исправление: nebularia (всего исправлений: 1)
Ответ на: комментарий от nebularia

А заодно выявит совсем уж убитые бэдблоки при их наличии

Ну это на HDD только. У меня такие соображения про бэды. Если hdd при записи в физический сектор заметит ошибку, то сразу ремапнет его и на файловой системе это никак не отразится (потому что диск расчехлит другой физический сектор из резервной области, оставив с тем же адресом).

Но вот, если после удачной записи через некоторое время данные перестали читаться без ошибки, то тут несовсем понятно. Файловая система, когда найдет ошибку, просто внесет кластер в ЧС и больше не будет использовать. И не важно, это программная ошибка или на харде.

А HDD при чтении физического сектора с повреждёнными данными отметит его в кандидаты на ремап, но не ремпапнет сразу. Таким образом не важно, программная ошибка или сектор сбойнул - в обоих случаях он залетает в чёрный список файловой системы.

Т.к. кластер в черном списке файловой системы, то в него больше не будет писаться. Даже если сектор физически исправен на блинах. А HDD не может его исключить из софтбедов, потому что в него нет попыток записи.

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

Всё правильно?

rnduser
() автор топика
Ответ на: комментарий от rnduser

Мне кажется ты считаешь жёсткие диски и файловые системы слишком умными. При натыкании на реальный бэд во время такой записи нулями у тебя всё очень надолго зависнет и скорее всего диск в итоге в прицепе отобьёт из системы по i/o error.

А fsck условной ext4 никакие бэды не ищет и не ремапит.

По поводу «решится» тут на мой взгляд у тебя два пути при обнаружении бэдов. Первый и правильный - слить данные с диска и отправить его на помойку. Второй - найти области с бэдами и разметить разделы вокруг них с запасом. Тогда если проблема была единичной, диск ещё долго проработает, но сильно надёжным его после такого считать всё равно нельзя.

nebularia ★★★
()
Последнее исправление: nebularia (всего исправлений: 2)
Ответ на: комментарий от nebularia

Да я запутался. Я не понимаю, как на уровне ФС составляется список битых кластеров. Задумался об этом, когда увидел совет заново чекать ошибки ФС после развёртывания образа (например vhd) на новый hdd. Чтобы спросить список битых блоков. Почему это надо делать и как вообще ФС помещает в ЧС конкретный блок? Битые кластеры не отражают ситуацию с проблемными физическими секторами (ну т.е. не обязательно). А если даже и так, то диск же заменит сектор, выдав тот же адрес файловой системе. С ремапом и курент пендинг секторами другая история. Фиг с ними.

Ещё хочет спросить, насколько безопасно делать secure erase на SSD через hdparm? Часто ssd с концами уходят в себя? Допустим, blkdiscard не сработал (в конкретной прошивке/контроллере). Всё таки это просто аналог trim, а трим может быть без поддержки zeroed или не исполняться немедленно и тогда данные останутся. Тогда остаётся SE.

Если я правильно понял, мы просто задаём пароль и блокируем диск. Затем пароль сбрасывается и диск разблокируется отправкой команды SE. Но при этом меняется ключ шифрования и уже записанные данные перестают читаться. Я так делал на HDD с поддержкой аппаратного шифрования. Все данные можно было стереть просто сбросив пароль, потому что на блинах оставалась не читаемая каша. Но на HDD для начала надо было включить шифрование. А в SSD оно вроде как должно быть изначально. Но если вдруг его там нет, то SE заставит SSD тереть все блоки как-то иначе.

rnduser
() автор топика