А зачем такое извращение?

ext3 ext4

man chattr

When  a  file  with  the `s' attribute set is deleted, its blocks are zeroed and written back to the disk.
       Note: please make sure to read the bugs and limitations section at the end of this document.
BUGS AND LIMITATIONS
       The `c', 's',  and `u' attributes are not honored by the ext2 and ext3 filesystems as implemented  in  the
       current mainline Linux kernels.

ещё не забудьте про

       A  file with the `j' attribute has all of its data written to the ext3 journal before being written to the
       file itself, if the filesystem is mounted with the "data=ordered" or "data=writeback" options.   When  the
       filesystem  is  mounted  with  the  "data=journal"  option  all  file  data is already journalled and this
       attribute has no effect.  Only the superuser or a process possessing the CAP_SYS_RESOURCE  capability  can
       set or clear this attribute.

ЗЫЖ если ФС это не поддерживает, пересоберите ядро или юзайте shred и не парьтесь.

А зачем такое извращение?

что-бы имена/явки/пароли можно было-бы УНИЧТОЖИТЬ простой rm -rf /*

А чем это хуже:

dd if=/dev/zero of=/dev/sda

Таки на ssd будут нули, после удаления данных (если включен -o discard)

А чем это хуже:

Тем, что ты ради удаления нескольких файлов ты убиваешь ФС на диске с потенциальным объемом сотни гиг, а secure deletion прибивает только нужные файлы и оставляет живую ФС.

Ты что-то путаешь. Наоборот, даже полное затирание не гарантирует, что данные на самом деле удалены. Ибо TRIM.

Слишком мало тормозит и слишком долго живут диски.

Есть же trim-test: https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledan...

Там как раз данные после удаление забиты нулями (если trim работает)

А если нужно не все удалить, то простого

find /home/ -type f -exec dd if=/dev/zero bs=10M count=10 of={} \;  rm -rf /home

Есть: ext2/ext3/ext4/fat. Но только AFAIK в моей сборке ядра.

А если нужно не все удалить, то простого

должно вполне хватить

Садись, два. На пересдачу.

Все уже сдано, профессор, в деканате под столом стоит! :)

Я так и не понял, для j и s патчить ничего не надо, оно уже в ванильном варианте есть?

А чем это хуже: dd if=/dev/zero of=/dev/sda

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

Таки на ssd будут нули, после удаления данных (если включен -o discard)

ты не понял: нули будут НЕ ТАМ. Сам железный контроллер подставляет рандомные блоки по одному и тому-же адресу. В HDD есть нечто подобное - реаллокация битых дорожек. Но в HDD это бывает очень редко, и в конце срока. А в SSD/Flash это by design изначально. И это НИКАК не лечится. У мну была битая флешка, я по наивности тоже хотел badblock пометить - дык он прыгал по всей флешке.

Ты что-то путаешь. Наоборот, даже полное затирание не гарантирует, что данные на самом деле удалены. Ибо TRIM.

ну TRIM не для этого вообще-то.

А если нужно не все удалить, то простого

man shred и не делай больше глупостей.

Я так и не понял, для j и s патчить ничего не надо, оно уже в ванильном варианте есть?

в том-то и дело, что НЕТ. Атрибуты ставятся, но данные НЕ обнуляются. Надо патчить...

Я так и не понял, для j и s патчить ничего не надо, оно уже в ванильном варианте есть?

Нет.

Нужно патчить. Или воспользоваться ядром, где УЖЕ пропатчено.

Но в HDD это бывает очень редко, и в конце срока.

Твои данные устарели. Сейчас и на HDD делают реаллокацию в процессе обычной работы - чтобы бенчмарками с конкурентами меряться.

в случае уменьшения файла сделать то же самое с высвобожденными блоками.

Это называется truncate. С точки зрения VFS delete делается тоже через truncate.

Но одних «высвобождаемых блоков» мало, потому как есть ещё и журнал (и возможность data=journal). Это тоже надо «чистить».

И есть ещё всякие «хитрые» FS (типа btrfs) со всякими COW, для которых это реализовать нетривиально. Для ext2/3/4 и FAT это реализуемо (что я делал - на базе существующих разных вариантов (старых, новых, разной степени готовности и глючности) + свои дополнения).

P.S. 's' атрибут - из набора ext2-специфичных, поэтому он возможен только в ext2-based FS. Для остальных это можно реализовать, например, опцией монтирования (скажем, -o secrm) (для FAT так и делал), но это уже менее гибко получается.

Твои данные устарели. Сейчас и на HDD делают реаллокацию в процессе обычной работы - чтобы бенчмарками с конкурентами меряться.

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

в случае уменьшения файла сделать то же самое с высвобожденными блоками.

Это называется truncate. С точки зрения VFS delete делается тоже через truncate.

truncate это просто освобождение блоков, БЕЗ их очистки.

Но одних «высвобождаемых блоков» мало, потому как есть ещё и журнал (и возможность data=journal). Это тоже надо «чистить».

в большинстве случаев в журнал НЕ пишутся данные, потому его не нужно чистить.

's' атрибут - из набора ext2-специфичных, поэтому он возможен только в ext2-based FS.

как раз наоборот - только в ext23(4?) атрибут s НЕ включен в апстрим. Впрочем про другие FS я не в курсе.

truncate это просто освобождение блоков, БЕЗ их очистки.

Да. Ты с кем споришь? Я где-то говорил про очистку при truncate?

в большинстве случаев в журнал НЕ пишутся данные, потому его не нужно чистить.

Что значит «в большинстве случаев»? data=jornal

Атрибут 's' - это security delete. Ключевое слово - «secrurity». Поэтому «чистить» нужно и метеданные в журнале, и записи в каталоге, чтобы не оставалось даже информации о удалённых файлах.

как раз наоборот - только в ext23(4?) атрибут s НЕ включен в апстрим.

В ext234 атрибут включется и отключается. Но никак не обрабатывается (игнорируется). В других (не-ext2-based FS) ты его просто НЕ включишь.

Впрочем про другие FS я не в курсе.

Похоже, ты ни про какие FS «не в курсе»:)

Анон, почему ты не под ником?

Анон, почему ты не под ником?

Добрый модератор пароль мне изменил.

Да. Ты с кем споришь? Я где-то говорил про очистку при truncate?

нет. Первый пост, на который ты ответил, ты тоже не прочитал?

Что значит «в большинстве случаев»? data=jornal

везде стоит по дефолту журналирование только метаданных, и очень мало кто включает журналирование данных.

Атрибут 's' - это security delete. Ключевое слово - «secrurity». Поэтому «чистить» нужно и метеданные в журнале, и записи в каталоге, чтобы не оставалось даже информации о удалённых файлах.

та я знаю. Я и писал про то, что секьюрность тут конфликтует с надёжностью, который обеспечивает журнал. Очевидно потому-то s и не в апстриме.

как раз наоборот - только в ext23(4?) атрибут s НЕ включен в апстрим.

В ext234 атрибут включется и отключается. Но никак не обрабатывается (игнорируется).

я что-то не так написал? Атрибут есть, только НЕ работает.

В других (не-ext2-based FS) ты его просто НЕ включишь.

уверен? Ну может быть и так - я ВСЕ ФС не проверил.

Похоже, ты ни про какие FS «не в курсе»:)

про ext2, ext3, и ext4 в курсе.

Я и писал про то, что секьюрность тут конфликтует с надёжностью, который обеспечивает журнал. Очевидно потому-то s и не в апстриме.

Не конфликтует. В журнале «чистится» только то, что относится к удвлённому. Всё остальное - на месте.

Не конфликтует. В журнале «чистится» только то, что относится к удвлённому. Всё остальное - на месте.

ага. _должно_ чистится, причём так, что-бы при _любом_ сбое это можно было откатить обратно. Как ты это себе представляешь? Это вообще, принципиально возможно? У тебя есть ответы?

ага. _должно_ чистится, причём так, что-бы при _любом_ сбое это можно было откатить обратно. Как ты это себе представляешь? Это вообще, принципиально возможно? У тебя есть ответы?

Да. Не только ответы, но и готовые рализации для ext3/jbd и ext4/jbd2

Не только ответы, но и готовые рализации для ext3/jbd и ext4/jbd2

ну давай что-ли пруфлинк, будем обсуждать. Мне только одно непонятно: jdb уже Over9000 лет юзается, но вот про использование jdb с атрибутом s я не слышал. Лично я не пробовал, однако очевидно, что сохранение данных будет конфликтовать с их уничтожением. Особенно если хочется делать и то и другое _надёжно_.

Впрочем, я не вижу смысла использовать data=journal, а с проблемами сохранности файлов предпочитаю справляться иначе. Вероятность порчи не настолько высока, что-бы хранить их(данные) дважды.

ну давай что-ли пруфлинк, будем обсуждать.

Уже без тебя «обсудили»:)

http://lwn.net/Articles/462398/

Im still not quite done debugging

я пожалуй подожду.

Порно с детьми же.

man rm:

-P Overwrite regular files before deleting them. Files are overwritten once with a random pattern. Files with multiple links will be unlinked but not overwritten.

В линуксах должно быть что-то похожее.

Да и shred есть. Вопрос не о том. Вопрос срабатывания данной фитчи при обычном POSIX-удалении.