☰

Атомарное удаление каталога

tag-icon • tag-icon linux rename mv concurrency
Атомарное удаление каталога

Поскольку rename(2)вызывается mv, можно ли с уверенностью предположить, что следующее будет атомарным?

$ mv /home/me/someDir /tmp/toBeDeleted
$ rm -rf /tmp/toBeDeleted

решение1

Themvкоманданазываетrenameсистемный вызов, который гарантированно является атомарным. Однако есть два исключения:

  • Если источник и место назначения находятся в разных файловых системах, что довольно распространено для /homevs. /tmp, то renameпроисходит сбой, и mvтогда происходит копирование исходного дерева в место назначения и последующее удаление исходного дерева. Очевидно, что это не атомарно.
  • Существуют файловые системы, где renameне является атомарным, например, некоторые реализации NFS. На любой «нормальной» локальной файловой системе renameявляется атомарным.

решение2

Если каталоги находятся на одном аппаратном разделе, смонтированном как одна файловая система, то перемещение чего-либо фактически является просто переименованием этого в другой путь. Однако если это не так, то каждый файл внутри, возможно, должен быть прочитан и скопирован, поэтому никакая часть перемещения не будет атомарной. Как указывает Жиль, POSIX предусматривает, что это относится к дискретным файловым системам.

За исключением этого, быстрая проверка с помощью straceconfirmed mvиспользует rename()системный вызов (не путать с rename, утилитой командной строки). Это сделало бы mving каталог атомарным с точки зрения пользовательского пространства. rename()Системный вызов выдаст ошибку EBUSY, если:

oldpath или newpath — это каталог, который используется каким-либо процессом (возможно, как текущий рабочий каталог, или как корневой каталог, или потому что он был открыт для чтения) или используется системой (например, как точка монтирования), в то время как система считает это ошибкой. (Обратите внимание, что в таких случаях нет необходимости возвращать EBUSY — в любом случае нет ничего плохого в выполнении переименования — но разрешается возвращать EBUSY, если система не может иначе обработать такие ситуации.)

Из man 2 rename. Связь с «атомарностью» здесь заключается в том, что вы не можете прервать другой процесс, работающий в каталоге, а другой процесс не может прервать этот — он выдаст ошибку типа «недопустимый путь/не найден», если вы его опередите.

решение3

Оба ответа по сути говорят об одном и том же, но фокусируются только на одном аспекте удаления.

Если у вас есть оболочка, рабочий каталог которой находится в переименованном/перемещенном дереве каталогов, она продолжит работу.видетьииспользоватьэти файлы, пока они не будут фактически удалены. Из-за этого оболочка будет видеть файлы в различных состояниях удаления, и, следовательно, переименование/перемещение (пока можетбыть"атомный"сам по себе) являетсянетатомарная форма удаления с точки зрения всех пользователей файлов. Она влияет только на пользователей, чья оболочка находится вне дерева каталогов с самого начала.

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

POSIX не дает четкого представления о причине такого поведения, но указывает на поведениеpwd(встроенная оболочка) иcd(встроенная оболочка).

Связанный контент