Классическая ситуация: я запустил плохо rmи сразу после этого понял, что удалил не те файлы. (Ничего критического, и у меня были сносные недавние резервные копии, но все еще раздражает.)
Зная, что дальнейшая активность на диске была моим врагом, если я хотел восстановить файлы с помощью extundeleteтаких инструментов, я сразу же выключил машину физически (т. Е. С помощью кнопки питания, а не с помощью haltлюбой такой команды). Это был ноутбук без каких-либо важных задач или что-то открытое, так что это была приемлемая операция. (Кстати, с тех пор я узнал, что первое, что нужно сделать в такой ситуации, - это сначала оценить, могут ли отсутствующие файлы все еще открываться процессом /unix//a/101247 - если они есть, вы должны восстановить их таким образом, а не выключать машину.)
Тем не менее, когда машина была выключена, я немного подумал и решил, что файлы не стоят затрат времени на загрузку работающей системы для надлежащей криминалистики. Поэтому я снова включил машину. А потом я обнаружил, что мои файлы все еще находятся на диске: rmони не были распространены на диск до того, как я выключился. Я немного потанцевал и поблагодарил бога сисадминов за его неожиданное прощение.
Мой вопрос теперь состоит в том, чтобы понять, как это было возможно, и какова типичная задержка перед rmфактическим распространением на диск. Я знаю, что дисковый ввод-вывод не сразу очищается, но он некоторое время находится в памяти, но я подумал, что журнал диска быстро убедится, что ожидающие операции не будут полностью потеряны. /unix//a/78766, похоже, намекает на отдельный механизм очистки грязных страниц и операций журнала, но не дает достаточно подробных сведений о том, как журнал будет задействован для rm, и ожидаемой задержке до операции сбрасываются.
Еще несколько подробностей: данные были в разделе ext4 внутри тома LUKS, и при перезагрузке машины я увидел следующее syslog:
Sep 24 10:24:58 gamma kernel: [ 11.457007] EXT4-fs (dm-0): 1 orphan inode deleted
Sep 24 10:24:58 gamma kernel: [ 11.458393] EXT4-fs (dm-0): recovery complete
Sep 24 10:24:58 gamma kernel: [ 11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
но я не уверен, что это связано с rm.
Другой вопрос заключается в том, существует ли способ заставить ядро не выполнять какие-либо ожидающие операции с диском (а, скажем, вывести их куда-нибудь), а не выключать компьютер. (Конечно, звучать опасно - не выполнять ожидающие операции, но это то, что произойдет при выключении машины в любом случае, и в некоторых случаях это может вас спасти.) Конечно, это будет «чище», а также интересно например, для удаленных серверов, где физическое отключение не является простым вариантом.
rm? Другими словами, вещи передаются в журнал только тогда, когда запись вот-вот должна быть выполнена? Или картина сложнее? Что касается alt-sysrq-u, это довольно изящная идея. У вас есть ссылка на претензию "Похоже"? (Похоже, это не следует из ссылок, которые вы дали.) Спасибо! :)