Что может вызвать перемещение / удаление файла NFS
Я не знаю ни о каком способе выполнить это использование, просто читал/писал/выполнял полномочия, которые находятся на файлах/каталогах. Однако можно использовать списки управления доступом (acls) - видят человека acl для получения информации о том, как они работают - и команда setfacl в особенности для установки полномочий.
Например:
$ setfacl -Rm u:foo:rwX,d:u:foo:rwX test
изменить текущий ACL, а также значение по умолчанию. Я верю "d": только влияет (d) efault на ACL каталогов и листовых нетронутых файлов. Затем при создании нового файла в каталоге он наследовал ACL своего родительского каталога через значение по умолчанию.
Ссылки
Краткий ответ: ваша локальная NFS не считает, что файл или каталог там есть. (да , вы как бы подозревали, что)
NFS - это старая технология. Она не предназначалась для высокодоступных, быстро меняющихся файлов. Для динамических общих файловых систем попробуйте кластерное решение, такое как OCFS2 (мой любимый) или gluster (meh , Dark Side).
Несколько лет назад у нас было 4 сервера, монтирующих общий NFS, и мы неоднократно обнаруживали, что сервер создает файл, который другие серверы не могут видеть. 4 сервера были серверами веб-приложений. Пользователь инициировал действие, которое бы h ave сервер создает пакет и по завершении обновляет строку в базе данных, указав путь NFS к файлу. Браузер пользователя будет проверять каждые 10 секунд, было ли выполнено задание и загружен ли файл.Вы можете видеть приближение проблемы - сервер обновит строку в БД, в которой находится файл, но другой сервер получит запрос от браузера пользователя - он пойдет, чтобы прочитать файл и получить ошибку «файл не найден».
Как вы сказали, к тому времени, когда администратор просмотрел его, файл был там. Чтобы найти проблему, потребовались недели, чтобы несколько из нас, инженеров, копали и копали. В основном мы запускали 10-секундный цикл ожидания, который получал путь к последнему созданному файлу, как указано в базе данных, и пытался сохранить файл в журнале. Постоянно система, создавшая файл, могла его видеть, но другие не могли в течение некоторого периода времени. Этот промежуток времени был больше, поскольку нагрузка на серверы увеличивалась.
Остроконечные боссы не хотели менять базовую NFS на кластерную файловую систему, поэтому вместо этого у нас также был рабочий сервер, за исключением того, что «он» был тем, кто создал файл в базе данных. Запрос пользователя будет повторяться до тех пор, пока задание не будет выполнено и запрос не поступит на сервер, создавший файл, чтобы он всегда был доступен для чтения. Да, я знаю. Kludge. Но это то, что вы получите, если решите сохранить старые технологии - вам придется потрудиться, чтобы все заработало. Старая технология - это первый кладж, и все, что сделано для работы с ним, - это просто еще один кладж. Добро пожаловать обратно в 80-е и в любимую компанию Max Headroom FS.
NFS не поддерживает синхронизацию всех клиентов со всеми изменениями в реальном времени.Таким образом, вы постоянно будете сталкиваться с условиями, когда один клиент создает файл / каталог, а другой его не видит, или когда один клиент удаляет файл / каталог, а другие клиенты думают, что он все еще существует (пока они не попытаются его использовать - упс ).
Мы испробовали всевозможные уловки, чтобы заставить системы повторно синхронизировать свой клиентский кеш перед попыткой чтения файла. Не происходит.
Моя рекомендация: принесите свою FS в этот век. (попробуйте конденсатор потока на скорости 88 миль в час)
просто замечание:
ошибка E155009 / E000018 также применяется к локальному перемещению между устройствами:
svn: E155009: Failed to run the WC DB work queue associated with '/first-device/mounted-device', work item 1219 (file-install /first-device/mounted-device/file-to-move-to 1 0 1 1)
svn: E000018: Can't move '/first-device/.svn/tmp/svn-v2KRIt' to '/first-device/mounted-device/file-to-move-to': Invalid cross-device link
Таким образом, он не зависит от NFS.