Перемещение каталога атомарно

Вы можете сделать это, если используете символические ссылки:

Допустим, alpha — это символическая ссылка на каталог alpha_1, и вы хотите переключить символическую ссылку, чтобы она указывала на alpha_2. Вот как это выглядит до переключения:

$ ls -l
lrwxrwxrwx alpha -> alpha_1
drwxr-xr-x alpha_1
drwxr-xr-x alpha_2

Чтобы альфа ссылалась на альфа_2, используйте ln -nsf:

$ ln -nsf alpha_2 alpha
$ ls -l
lrwxrwxrwx alpha -> alpha_2
drwxr-xr-x alpha_1
drwxr-xr-x alpha_2

Теперь вы можете удалить старый каталог:

$ rm -rf alpha_1

Обратите внимание, что на самом деле это НЕ полностью атомарная операция, но это происходит очень быстро, поскольку команда «ln» одновременно удаляет ссылку, а затем немедленно воссоздает символическую ссылку. Вы можете проверить это поведение с помощью strace:

$ strace ln -nsf alpha_2 alpha
...
symlink("alpha_2", "alpha")             = -1 EEXIST (File exists)
unlink("alpha")                         = 0
symlink("alpha_2", "alpha")             = 0
...

Вы можете повторить эту процедуру по желанию: например. когда у вас есть новая версия, alpha_3:

$ ln -nsf alpha_3 alpha
$ rm -rf alpha_2

Окончательное решение сочетает подход с символической ссылкой и переименованием:

mkdir alpha_real
ln -s alpha_real alpha

# now use "alpha"

mkdir beta_real
ln -s beta_real tmp 

# atomically rename "tmp" to "alpha"
# use -T to actually replace "alpha" instead of moving *into* "alpha"
mv -T tmp alpha

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

Взяв здесь решение Дэвида, которое полностью атомарно ... единственная проблема, с которой вы столкнетесь, заключается в том, что параметр -T для mv не является POSIX, и поэтому некоторые ОС POSIX могут его не поддерживать (FreeBSD, Solaris и т. ... http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html). С небольшой модификацией этот подход можно изменить, чтобы он стал полностью атомарным и переносимым на все ОС POSIX:

mkdir -p tmp/real_dir1 tmp/real_dir2
touch tmp/real_dir1/a tmp/real_dir2/a
# start with ./target_dir pointing to tmp/real_dir1
ln -s tmp/real_dir1 target_dir
# create a symlink named target_dir in tmp, pointing to real_dir2
ln -sf tmp/real_dir2 tmp/target_dir
# atomically mv it into ./ replacing ./target_dir
mv tmp/target_dir ./

пример через: http://axialcorps.wordpress.com/2013/07/03/atomically-replacing-files-and-directories/

Начиная с Linux 3.15, новый системный вызов renameat2 может атомарно обмениваться двумя путями в одной и той же файловой системе. Однако для него пока нет даже оболочки glibc, не говоря уже о способе доступа к нему с помощью coreutils. Таким образом, это будет выглядеть примерно так:

int dirfd = open(".../base", O_PATH | O_DIRECTORY | O_CLOEXEC);
syscall(SYS_renameat2, dirfd, "alpha", dirfd, "bravo", RENAME_EXCHANGE);
close(dirfd);
system("rm -rf alpha");

(Конечно, вы должны правильно обрабатывать ошибки и т. д. — см. эту суть для более сложной renameat2 обертка.)

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

Обновление 2020: оболочка glibc для этого системного вызова доступна, начиная с glibc 2.28, выпущенного 01 августа 2018 г. (Debian Stretch, Fedora 29). Однако он по-прежнему недоступен через coreutils.

int dirfd = open(".../base", O_PATH | O_DIRECTORY | O_CLOEXEC);
renameat2(dirfd, "alpha", dirfd, "bravo", RENAME_EXCHANGE);
close(dirfd);
system("rm -rf alpha");

Используйте отдельную гарантированно атомарную операцию в качестве семафора.

Итак, если операции создания и удаления файла атомарны:

1) создайте файл с именем «семафор».

2) Если и только если это успешно (нет конфликта с существующим файлом), выполните операцию (либо обработайте альфа-канал, либо переместите каталог, в зависимости от процесса)

3) rm семафор.

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

mv alpha delta
mv bravo alpha
rm -rf delta

но у этого все еще было бы маленькое окно, где альфа не существовало.

Чтобы свести к минимуму вероятность того, что что-либо попытается использовать альфу, пока ее нет, вы можете (если у вас есть полномочия):

nice --20 ( mv alpha delta ; mv bravo alpha )
rm -rf delta

что значительно повысит приоритет вашего процесса, пока выполняются операции mv.

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

Раздел документации SQLite Блокировка файлов и параллелизм в SQLite версии 3 содержит хорошо написанное описание протокола эскалации блокировки для управления одновременным чтением, эксклюзивной записью и откатом после сбоя. . Некоторые из этих идей применимы и здесь.

Это должно помочь:

mkdir bravo_dir alpha_dir
ln -s bravo_dir bravo
ln -s alpha_dir alpha
mv -fT bravo alpha

strace mv -fT bravo alpha показывает:

rename("bravo", "alpha")

который выглядит довольно атомарным для меня.

Даже если бы вы обращались к инодам напрямую, все равно не было бы возможности атомарно поменять местами значения инодов в пользовательском пространстве.

Беспокоиться об атомарности операции бессмысленно. Дело в том, что доступ к альфе другой задачей все равно не будет атомарным.

Семафорный подход странного мышления — единственный выход.

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

Я не верю, что есть атомный способ сделать это. Лучше всего сделать что-то вроде этого:

mv alpha delme
mv bravo alpha
rm -rf delme

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

mv и ln могут использоваться для атомарных операций. Я использовал ln(1) для атомарного развертывания веб-приложений.

Правильный способ замены символической ссылки — с помощью ln -nsf

ln -nsf <target> <link_name>

e.g.

$ mkdir dir1
$ mkdir dir2
$ ln -s dir1 mylink
$ ls -l mylink
lrwxrwxrwx  1 phil phil 4 Nov 16 14:45 mylink -> dir1
$ ln -nsf dir2 mylink
$ ls -l mylink
lrwxrwxrwx  1 phil phil 4 Nov 16 14:46 mylink -> dir2

Также можно заменить целые части контента сразу в каком-то префиксе (здесь Z) с помощью unionfs-fuse:

# mkdir a b c Z
# touch a/1 b/2 c/3
# ln -s a X
# ln -s b Y
# unionfs X=RW:Y=RW Z
# shopt -s globstar
# file **
a:   directory
a/1: empty
b:   directory
b/2: empty
c:   directory
c/3: empty
X:   symbolic link to a
Y:   symbolic link to b
Z:   directory
Z/1: empty
Z/2: empty
# ln -sfn c Y
# file **/*
a:   directory
a/1: empty
b:   directory
b/2: empty
c:   directory
c/3: empty
X:   symbolic link to a
X/1: empty
Y:   symbolic link to c
Y/3: empty
Z:   directory
Z/1: empty
Z/3: empty
# fusermount -u Z
# rm -r a b c X Y Z

mount --bind bravo alpha должен сделать это в Linux

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

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

Вы также должны быть осторожны с процессами, имеющими открытый дескриптор в каталоге или подкаталоге alpha (например, cwd).

У других *nix могут быть подобные трюки в рукаве, но они не стандартизированы.

Почему бы вам просто не сделать что-то вроде:

rm -rf alpha/*
mv bravo/* alpha/
rm -rf bravo/

Это означает, что все в альфа-версии уничтожается, альфа-версия никогда не удаляется, а все содержимое перемещается.