Может ли файловая система стать несовместимой, если прервалась при перемещении файла?

У меня есть две папки в одном разделе (EXT2). Если mv folder1/file folder2произойдет какое-либо прерывание (например, сбой питания), может ли файловая система оказаться несовместимой?

Разве mvоперация не атомарна?

Обновление: до сих пор на IRC я ​​получил следующие перспективы:

1. это атомно, поэтому несоответствия не могут произойти
2. сначала вы копируете запись dir в новый dir, а затем удаляете запись в предыдущем dir, так что у вас может быть несогласованность наличия ссылки на файл дважды, но счетчик ссылок равен 1
3. сначала он стирает указатель, а затем копирует указатель, поэтому несоответствие заключается в том, что файл имеет ссылку 0

Может кто-нибудь уточнить?

Во-первых, давайте развеем некоторые мифы.

это атомно, поэтому несоответствия не могут произойти

Перемещение файла внутри одной и той же файловой системы (т. Е. renameСистемного вызова) является атомарным по отношению к программной среде. Атомарность означает, что любой процесс, который ищет файл, увидит его в старом или новом месте; ни один процесс не сможет заметить, что файл имеет другое количество ссылок, или что файл присутствует в исходном каталоге после того, как он присутствует в целевом каталоге, или что файл отсутствует в целевом каталоге после того, как он отсутствует в источнике каталог.

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

сначала вы копируете запись dir в новый dir, а затем удаляете запись в предыдущем dir, так что у вас может быть несогласованность наличия ссылки на файл дважды, но счетчик ссылок равен 1

Это относится к конкретной технике реализации. Есть и другие.

Так получилось, что ext2 в Linux (начиная с ядра 3.16) использует именно эту технику. Однако это не означает, что содержимое диска проходит через последовательность [старое местоположение] → [оба местоположения] → [новое местоположение], поскольку две операции (добавление новой записи, удаление старой записи) также не являются атомарными на аппаратном уровне. : возможно, что один из них будет прерван, оставив файловую систему в несогласованном состоянии. (Надеюсь, fsck восстановит его.) Кроме того, слой блоков может переупорядочить записи, поэтому первая половина может быть записана на диск непосредственно перед сбоем, а вторая половина не будет выполнена.

Счетчик ссылок никогда не будет отличаться от 1, пока не произойдет сбой системы (см. Выше), но эта гарантия не распространяется на сбой системы.

сначала он стирает указатель, а затем копирует указатель, поэтому несоответствие заключается в том, что файл имеет ссылку 0

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

Согласно сообщению в блоге Александра Ларссона , ext2 не дает гарантии согласованности при сбое системы, но ext3 работает в этом data=orderedрежиме. (Обратите внимание, что этот пост в блоге не о renameсебе, а о комбинации записи в файл и обращения renameк этому файлу.)

Теодор Цо, главный автор файловых систем ext2, ext3 и ext4, написал сообщение в блоге на эту же тему . В этом сообщении в блоге обсуждается атомарность (только в отношении программной среды) и долговечность (то есть атомарность в отношении сбоев плюс гарантия обязательства, то есть знание того, что операция была выполнена). К сожалению, я не могу найти информацию об атомарности в отношении одних аварий. Однако гарантии долговечности, данные для ext4, требуют renameатомной защиты. Документация ядра для ext4 гласит, что ext4 с auto_da_allocопцией (которая по умолчанию в современных ядрах), а также ext4, обеспечивает гарантию долговечности для writeследующегоrename, что подразумевает renameатомарность в отношении аппаратных сбоев.

Для Btrfs a, renameкоторый перезаписывает существующий файл , гарантированно является атомарным по отношению к сбоям, но a rename, который не перезаписывает файл, может привести к тому, что ни один файл, ни оба файла не существуют.

Таким образом, ответ на ваш вопрос заключается в том, что не только перемещается файл, не являющийся атомарным в отношении сбоев на ext2, но даже не гарантируется, что файл останется в согласованном состоянии (хотя сбои, которые fsckне могут быть исправлены, редки) - почти ничего не происходит, поэтому были изобретены лучшие файловые системы. Ext3, ext4 и btrfs предоставляют ограниченные гарантии.

Операция переименования очень быстрая в любой файловой системе, поэтому она вряд ли будет прервана, но в классической файловой системе она, безусловно, может быть прервана - если она сначала создает ссылку назначения, она может оставить две ссылки в файле - что допустимо, но файл думает, что у него есть только один файл , что может вызвать проблемы, если его удалить позже. С другой стороны, если сначала удалить исходную ссылку, файл может быть потерян. Запуск fsck обычно обнаруживает и исправляет любое условие, хотя, если файл потерян, он будет помещен в каталог «lost + found» с произвольным именем, а не в нужное место - и если он имеет две ссылки, счетчик ссылок просто обновляться, поэтому файл будет существовать в двух местах, если файловая система поддерживает это.

Если вам требуется, чтобы файловая система была устойчивой в случае сбоев питания, вам следует использовать журналируемую файловую систему , такую ​​как NTFS, EXT3 или XFS. В большинстве современных систем по умолчанию используется файловая система журналирования, хотя вы должны знать, что FAT не является файловой системой журналирования, если вы используете ее для внешних накопителей.

Журналируемая файловая система использует систему «двойной записи» - она ​​записывает в файл журнала тот факт, что намеревается переместить его, а затем выполняет перемещение. Когда файловая система проверяется при запуске, если она была прервана, она заметит, что перемещение не было завершено, и затем вернет ее.

Существует два типа ведения журнала файловых систем - ведение журнала метаданных и полное ведение журнала. Ведение журнала метаданных означает, что оно не отслеживает изменения содержимого файлов в системе журналов (поэтому вы можете в конечном итоге потерять содержимое при записи в файл), но все равно будет отслеживать важную информацию файловой системы, такую ​​как содержимое каталога. , свойства файла и т. д.

Когда люди говорят о том, что операция переименования является атомарной, они имеют в виду, что она не может быть замечена в середине перехода другим процессом в системе, и ее нельзя оставлять наполовину завершенной, например, прерывая mvсаму команду ^C. Физический процесс записи в каждый каталог, чье пространство хранения может находиться в разных местах на диске, не может быть действительно атомарной операцией на аппаратном уровне.

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

Этот вопрос был задан немного по-другому на Super User. Страница Wikipedia в mvкоманде также объясняет это довольно хорошо:

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

Linux имеет переименованный syscall и, следовательно, переименует файл как атомарную, т. Е. Бесперебойную операцию. Так что нет, файловая система не может стать несовместимой в описанной вами ситуации.