Кеш NFS: вміст файлу не оновлюється на клієнті при зміні на сервері

11

Ось моя настройка: одна машина сервера NFS (v4), кілька клієнтських машин NFS.

Коли клієнтська машина записує файли на кріплення NFS, інші клієнти бачать новий вміст миттєво: немає проблем.

Але, коли серверна машина модифікує вміст файлу, цей новий вміст не відображається на клієнті, поки я не зроблю lsкаталог з клієнта.

Я абсолютно наткнувся на цю непослідовність ... будь-яка допомога буде дуже вдячна!

Інформація:

nfs 1.2.3-r1 як для клієнта, так і для сервера
acregmin, acregmax, acdirmin, acdirmax, lookupcache: значення за замовчуванням

nfs

— числоxiii
джерело

1

Чи можете ви зробити невеликий експеримент для отримання додаткової інформації? Зробіть ls -iклієнт, перш ніж редагувати файл на сервері, а потім знову після. Подивіться, чи змінюються цифри. Якщо вони роблять це через те, що сервер замінює файл, і клієнт цього не помічає, поки він не скасує каталог. Якщо так, спробуйте встановити параметр кріплення lookupcache=noneі побачити, чи зміниться поведінка.

— Патрік

2

Вибачте за затримку. Інод ефективно змінюється. Я додав варіант пошуку, схоже, він працює. Я завтра перевірю.

— числоxiii

11

Додавання як відповідь на основі вашого коментаря.
Рішення полягає в тому, щоб додати lookupcache=noneдо своїх параметрів кріплення nfs.

Що трапляється, що перший раз, коли ваш клієнт читає файл, він здійснює пошук NFS, щоб отримати файл NFS. Потім він кешує файловий файл NFS, а коли ви повернетесь, щоб відкрити файл, він використовує кеш. Зазвичай це не проблема, як при оновленні файлу, його fileid залишається таким же. Але чомусь старий файл видаляється, а новий створюється (або перейменовується, або щось там, де його не той самий файл).
Зараз зазвичай це не проблема, як тоді, коли ваш клієнт намагається відкрити файл, який там не знаходиться, він отримає помилку від сервера і зробить інший пошук, щоб отримати новий файлід. Але чомусь сервер NFS дозволяє клієнту відкрити цей старий файлід. Можливо, інший клієнт відкрив файл, і тому його ще не видалено, я не знаю.

У будь-якому випадку спосіб вирішити це - сказати клієнту завжди робити nfslookup перед відкриттям файлу, використовуючи опцію монтажу nfs lookupcache=none. Мінус цього полягає в тому, що це може бути дорого, якщо ви часто відкриваєте файли, оскільки це додає більше трафіку на сервер NFS.

— Патрік
джерело

Дякуємо за ваше пояснення. На сервері NFS стек експортованого каталогу - DRBD / LVM / ext4. Можливо, це викликає "помилку". У мене є проблема на декількох клієнтах, але не на деяких інших ... Я повторю всі свої тести і скажу, чи все добре з цим варіантом.

— числоxiii

0

Змініть параметр кріплення на hard,intr. Я думаю, що за замовчуванням у вашій системі може бути м'яким. це допоможе.

— johnshen64
джерело

на жаль, додавання цих параметрів кріплення нічого не змінило :(

— numberxiii

Під час мого першого випробування роблю переказ. Тоді я зробив тест від іншого клієнта, з чистим кріпленням. Здається, проблема виправлена: ми чекаємо 30-х років, щоб побачити новий вміст

— numberxiii

Я будую нового клієнта (vm), щоб перевірити: немає проблем із вмістом!

— числоxiii

1

@ johnshen64 чому ти думаєш, що важко вирішить проблему? Жорстке / м'яке значення має лише те, що стосується переривання з'єднання, не має нічого спільного з кешуванням.

— Патрік

0

Ви також можете вручну оновити кеш NFS

sudo mount /nfs-mount -o remount

... якщо ви не хочете додавати жодних параметрів кріплення, що погіршують продуктивність.

— Janne
джерело