StarMAUGLI писал(а): ↑08 дек 2018, 21:41
Не соглашусь. Я проверил свое заявление экспериментально. О чем и рассказал. Возможно, что раньше было именно так, как ты рассказываешь, но с развитием ОС были сделаны какие-то защитные механизмы чтобы стало возможным подобное использование команды dd? Так что аналогия на мой взгляд не уместна.
Объясняю "грязные подробности". Но тут сначала надо понимать, как у linux устроены "блокировки" файлов.
В винде, если вы, скажем открыли один файл на запись, до его закрытия винда вообще не позволит обращаться к файлу из другого процесса.
В линуксе это работает немного не так. Вы можете открыть один файл на запись из двух процессов, и ошибки это не вызовет. Само по себе. (Есть отдельный механизм полноценной блокировки, но включается он далеко не по дефолту). А по дефолту происходит вот что: процессы получают как бы свою виртуальную копию файла, куда и пишут. Однако на диске файл останется тот, который был закрыт последним. Не записан, а именно закрыт - это разные операции. Но это в простом случае - если файл небольшой. А если он целиком в память не влазит? В случае если файл большой, и целиком в память не влазит, начинается проблема. Система уже не может полностью разделить операции двух процессов и сохранить единую версию файла. Чтение и запись начинают иметь дело с диапазонами файла и перезаписывать его частично - это называется race conditions или concurent modifications. В этом случае файл будет скорее всего испорчен, т.к. получит "куски" от разных версий/процессов. Потому, программы для работы с большими файлами обычно включают полноценную блокировку. Однако dd этого не делает, т.к. работает на низком уровне, и считает, что оператор сам точно знает что делает.
Теперь вспоминаем правило "все есть файл". Что получается? Если раздел примонтирован в режиме rw - это файл открытый на запись. Причем огромного размера, по отношению к памяти. А тут мы его начинаем читать - т.е. получаем "копию". Если файл не изменился - все может обойтись, вот только шанс на это не то, чтобы очень большой, т.к. структуры каталогов кешируются в память и изменяются сначала там. А еще есть журналы FS, где хранятся данные по завершенным операциям, и которые не будут записаны сразу, а следовательно - в "виртуальной копии" не совпадут с тем состоянием в котором окажется структура каталогов. Более того - монтирование и отмонтирование FS тоже пртоколируются в журналах самой FS. Т.е. если клонировать не отмонтированную FS она и будет в таком состоянии, а попытка смонтировать ее следующий раз может вызовет механизм уборки мусора - отката незавершенных операций (который выполняется и в том случае, если выдернуть комп из розетки).
Конечно, если дать команду sync перед началом копирования dd, шанс получить в копии битый раздел меньше. Но все равно достаточно велик, т.к. когда ядру захочется полезть на раздел и тем самым вызвать изменения (все операции логируются в журнале FS) - ты не предскажешь. Т.к. часть операций специально подгадывается к моментам простоя - чтобы не мешать основным дисковым операциям. Гарантию того, что копия будет действительно копией, может дать только состояние, когда ядро к разделу обратится не может в принципе.
Потому следует запомнить, и зарубить себе на носу - с помощью dd работать исключительно с отмонтированными файлами и разделами. (Не оговорка - имеются в виду файлы-образы, которые тоже можно смонтировать).
тяжёлый случай. и что, всё там напихано действительно необходимо?
Создавать их, а затем героически преодолевать - это моё хобби. 
