У нас возникла странная проблема, когда создание / удаление файла из клиента NFS занимает очень много времени, чтобы распространиться на другой клиент (ы).
У нас есть следующие варианты крепления для клиентов:
defaults,rsize=32768,wsize=32768,intr,noatime,cto
В экспорте есть:
*(rw,sync,no_root_squash,no_wdelay)
Мы проверяем это на одном клиенте, выполнив:
watch -n0.1 stat foofile
А на другом клиенте трогаем foofile (или rm его). Изменения распространяются через 1+ секунды.
cto и no_wdelay - это параметры, которые мы недавно добавили, чтобы посмотреть, решают ли они проблему (а это не так). Что еще мы можем посмотреть?
Я не собираюсь отвечать на ваш вопрос прямо.
Не гарантируется, что клиенты NFS увидят обновления очень быстро. Да, вы можете настроить параметры для управления задержкой, но результатом будет худшее кеширование (и, следовательно, ужасная производительность) на клиентах.
Обычно, когда мне нужны клиенты NFS, чтобы быстрее увидеть изменения, я делаю шаг назад и спрашиваю: «Хорошо, чего я действительно пытаюсь здесь достичь?» Обычно я понимаю, что существует некоторый более высокий уровень абстракции, который позволяет мне решить ту же проблему совершенно другим способом. Например, иногда я понимаю, что пытаюсь использовать файлы NFS как RPC для бедняков или механизм блокировки. Есть гораздо лучшие способы сделать то и другое.
NFS хорош для доступа одного клиента к определенному каталогу. Кроме того, если у вас есть проблема и вы собираетесь исправить ее с помощью NFS, у вас есть две проблемы.
Я люблю NFS, но он ограничен в том, где я пытаюсь его использовать.
Это ни в коем случае не является вашей проблемой, но я иногда обнаруживал проблемы с согласованностью с NFS, когда не все клиенты и сервер имеют жестко синхронизированные часы. Все ли затронутые системы синхронизированы с NTP?