Убедитесь, что состояние файла на клиенте синхронизировано с сервером NFS

Я пытаюсь найти правильный способ обработки устаревших данных на клиенте NFS. Рассмотрим следующий сценарий:

  • два сервера монтируют одно и то же общее хранилище NFS с количеством файлов
  • клиентское приложение на 1 сервере удаляет некоторые файлы
  • клиентское приложение на 2 сервере пытается получить доступ к удаленным файлам и терпит неудачу с: устаревшим дескриптором файла NFS (ничего странного, ожидается Ошибка)

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

Вот что я пытаюсь понять:

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

Спасибо.

3 9
linux nfs

3 ответа:

  • есть ли надежный способ проверить, что файл присутствует? В сценарии, приведенном выше, lstat на файл возвращает успех, и приложение завершает работу только после попытки переместить файл.

Это нормальное поведение NFS.

  • Как я могу вручную синхронизировать содержимое каталога на клиенте с сервером?

Это невозможно сделать вручную, так как NFS претендует на то, чтобы быть нормальной POSIX-совместимой файловой системой.

Я пытался один раз закодировать close () / open () в попытке хоть как-то смягчить последствия кэширования на стороне клиента NFS. В моем случае мне нужно было прочитать информацию, записанную в файл на другом сервере. Но даже трюк с повторным открытием дал почти нулевой эффект. И я не могу добавить fdatasync () в сторону записи, так как это замедляет работу всего приложения.

Мой опыт работы с NFS на сегодняшний день таков, что вы ничего не можете сделать. В критических путях кода я просто кодировал, чтобы повторить файловые операции, которые возвращают ESTALE.
  • некоторые общие рекомендации о том, как написать надежный код управления файлами в случае NFS?

Мод меня вниз все, что вы хотите, но если ваши клиенты хотят надежности, то они не должны использовать NFS.

Моя компания, например, рекламирует использование правильной распределенной файловой системы (я намеренно опускаю бренд), если клиент хочет надежности. Наше основное программное обеспечение не гарантировано для работы на NFS, и мы не поддерживаем такие конфигурации. Но в нашем случае нам действительно нужны гарантии что как только данные записываются в FS, они становятся доступными на всех других узлах. Когерентность в NFS может быть достигнута, но за счет производительности, что делает NFS практически бесполезной. (Проверьте его параметры монтирования.) NFS кэширует как сумасшедший, чтобы скрыть тот факт, что это файловая система сервера. Чтобы сделать все операции согласованными, клиент NFS должен был бы синхронно обращаться к серверу NFS для каждой небольшой операции, минуя локальный кэш. И это никогда не будет быстро.

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

11

Вы можете попробовать опцию монтирования "noac"

От man nfs:

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

Использование опции noac обеспечивает большая согласованность кэша между СЕТЕВАЯ ФАЙЛОВАЯ СИСТЕМА клиенты, обращающиеся к тем же файлам, но он извлекает значительную производительность штраф. Как таковое, разумное использование вместо этого рекомендуется блокировка файлов.

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

Кроме того, посмотрите на блокировку NFS и ее ограничения.

Что касается общих рекомендаций:

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

В той же файловой системе эта операция должна быть атомарной.

4

Мне удалось сделать ls -l в каталоге, содержащем файл.

2