Удостоверьтесь, что состояние файла на клиенте находится в синхронизации с сервером NFS
Я пытаюсь найти надлежащий способ обработать устаревшие данные на клиенте NFS. Рассмотрите следующий сценарий:
- Два сервера монтируют ту же совместно используемую память NFS с количеством файлов
- Клиентское приложение на 1 сервере удаляет некоторые файлы
- Клиентское приложение на 2 попытках сервера получить доступ к удаленным файлам и сбоям с: Лишите дескриптор файла NFS новизны (ничто странное, ошибка ожидается),
(Также может быть полезно знать, тот кэш монтируют, что опции довольно высоки на обоих серверах по причинам производительности).
То, что я пытаюсь понять:
- Там надежный метод должен проверить, тот файл присутствует? В сценарии, данном выше lstat на успехе возвратов файла и приложении, перестал работать только после попытки переместить файл.
- Как я могу вручную синхронизировать содержание каталога на клиенте с сервером?
- Некоторый генерал консультирует по вопросам того, как написать надежный код управления файлами в случае NFS?
Спасибо.
2 ответа
- Есть ли надежный способ проверить наличие этого файла? В приведенном выше сценарии lstat для файла возвращает успех, а приложение терпит неудачу только после попытки переместить файл.
Это нормальное поведение NFS.
- Как я могу вручную синхронизировать содержимое каталога на клиенте с сервером?
Это невозможно сделать вручную, поскольку NFS выдает себя за обычную POSIX-совместимую файловую систему.
Однажды я попытался написать код close () / open (), пытаясь как-то смягчить эффекты кэширования на стороне клиента NFS. В моем случае мне нужно было прочитать информацию, записанную в файл на другом сервере.Но даже повторное открытие имело практически нулевой эффект. И я не могу добавить fdatasync () к стороне записи, поскольку это замедляет работу всего приложения.
Мой опыт работы с NFS на сегодняшний день показывает, что вы ничего не можете сделать. В критических путях кода я просто закодировал повторение файловых операций, возвращающих ESTALE.
- Некоторые общие советы, как написать надежный код управления файлами в случае NFS?
Измените все, что хотите, но если вашим клиентам нужна надежность, им не следует использовать NFS.
Моя компания, например, рекламирует использование надлежащей распределенной файловой системы (я намеренно опускаю бренд), если заказчик хочет надежности. Не гарантируется, что наше основное программное обеспечение будет работать в NFS, и мы не поддерживаем такие конфигурации. Но в нашем случае нам действительно нужны гарантии, что как только данные будут записаны в ФС, они станут доступны на всех остальных узлах.
Когерентность в NFS может быть достигнута, но за счет производительности, что делает NFS практически непригодной для использования. (Проверьте его параметры монтирования.) NFS кэширует как сумасшедший, чтобы скрыть тот факт, что это файловая система сервера. Чтобы сделать все операции согласованными, клиент NFS должен будет синхронно обращаться к серверу NFS для каждой небольшой операции, минуя локальный кеш. И это никогда не будет быстрым.
Но поскольку мы говорим здесь о Linux, можно посоветовать клиентам программного обеспечения оценить доступные файловые системы кластера. Например. RedHat теперь официально поддерживает GFS . Я слышал о людях, использующих CodaFS, но у меня нет точной информации об этом.
Вы можете попробовать опцию монтирования ''noac''
из man nfs:
В дополнение к предотвращению клиента кэшировать атрибуты файлов, опция noac заставляет запись приложений стать синхронной, так что локальные изменения в файле становятся видимыми на на сервере немедленно. Таким образом, другие клиенты могут быстро обнаружить недавние записи, когда они проверяют атрибуты файла.
Использование опции noac обеспечивает большую согласованность кэша среди клиентов NFS клиентов, обращающихся к одним и тем же файлам, но это влечет за собой значительное снижение производительности штраф. Поэтому вместо этого рекомендуется разумное использование блокировки файлов.
Вы можете иметь два монтирования, одно для критических быстро меняющихся данных, которые вам нужно синхронизировать, и другое монтирование для других данных.
Также изучите блокировку NFS и ее ограничения.
Что касается общих советов:
Один из способов усечения файла, который одновременно читается с нескольких хостов, - это запись содержимого во временный файл, а затем переименование этого файла в конечное место.
На одной и той же файловой системе эта операция должна быть атомарной.