Pamięć podręczna NFS: zawartość pliku nie jest aktualizowana na kliencie po modyfikacji na serwerze


11

Oto moja konfiguracja: jedna maszyna serwera NFS (v4), kilka maszyn klienta NFS.

Gdy komputer kliencki zapisuje pliki na montażu NFS, inni klienci natychmiast widzą nową zawartość: bez problemu.

Ale kiedy komputer serwera zmodyfikuje zawartość pliku, ta nowa zawartość nie jest wyświetlana na kliencie, dopóki nie zrobię lskatalogu z klienta.

Jestem absolutnie zaskoczony tą niekonsekwencją ... każda pomoc byłaby bardzo mile widziana!

Informacje:

  • nfs 1.2.3-r1 na kliencie i serwerze
  • acregmin, acregmax, acdirmin, acdirmax, lookupcache: wartości domyślne

1
Czy możesz zrobić mały eksperyment, aby uzyskać więcej informacji? Wykonaj polecenie ls -ina kliencie przed edycją pliku na serwerze, a następnie ponownie. Sprawdź, czy liczby się zmienią. Jeśli to zrobią, ponieważ serwer zastępuje plik, a klient nie zauważy tego, dopóki nie przeskanuje katalogu. Jeśli tak, spróbuj ustawić opcję montowania lookupcache=nonei sprawdź, czy zachowanie się zmieni.
Patrick,

2
przepraszam za opóźnienie. I-węzeł skutecznie się zmienia. Dodałem opcję odnośnika, wydaje się, że działa. Sprawdzę jutro.
numberxiii

Odpowiedzi:


11

Dodanie jako odpowiedzi na podstawie Twojego komentarza.
Rozwiązaniem jest dodanie lookupcache=nonedo opcji montowania NFS.

Dzieje się tak, że gdy klient po raz pierwszy odczytuje plik, szuka NFS, aby uzyskać identyfikator pliku NFS. Następnie buforuje identyfikator pliku NFS, a gdy wrócisz, aby otworzyć plik, używa pamięci podręcznej. Zwykle nie stanowi to problemu, ponieważ po zaktualizowaniu pliku jego identyfikator pliku pozostaje taki sam. Ale z jakiegoś powodu stary plik jest usuwany, a nowy jest tworzony (lub zmieniany jego nazwa, lub coś, co nie jest tym samym plikiem).
Teraz zwykle nie stanowi to problemu, ponieważ gdy klient próbuje otworzyć identyfikator pliku, którego tam nie ma, otrzyma błąd z serwera i wykona kolejne wyszukiwanie, aby uzyskać nowy identyfikator pliku. Ale z jakiegoś powodu serwer NFS pozwala klientowi otworzyć stary identyfikator pliku. Być może inny klient ma otwarty plik, więc nie został jeszcze usunięty, nie wiem.

W każdym razie sposobem na rozwiązanie tego jest powiedzenie klientowi, aby zawsze otwierał nfslookup przed otwarciem pliku za pomocą opcji montowania nfs lookupcache=none. Wadą tego jest to, że może być kosztowne, jeśli często otwierasz pliki, ponieważ powoduje to większy ruch na serwerze NFS.


Dziękuję za wyjaśnienia. Na serwerze NFS stosem wyeksportowanego katalogu jest DRBD / LVM / ext4. Może to powodować „błąd”. Mam problem z kilkoma klientami, ale nie z niektórymi innymi ... Ponów wszystkie moje testy i powiem ci, czy wszystko idzie dobrze z tą opcją.
numberxiii

0

Zmień opcję montowania na hard,intr. myślę, że domyślnie może być miękkie w twoim systemie. to pomoże.


niestety dodanie tych opcji montowania nic nie zmieniło :(
numberxiii 18.04.

Do pierwszego testu przeprowadzam ponowny montaż. Potem zrobiłem test z innego klienta, z czystym montażem. Wydaje się, że problem został rozwiązany: czekamy 30
sekund,

Zbudowałem nowego klienta (VM) do sprawdzenia: nie ma problemu z treścią!
numberxiii

1
@ johnshen64, dlaczego uważasz, że trudno rozwiązać problem? Twardy / miękki ma znaczenie tylko w przypadku przerwania połączenia, nie ma nic wspólnego z buforowaniem.
Patrick,

0

Możesz także ręcznie odświeżyć pamięć podręczną NFS

sudo mount /nfs-mount -o remount

... w przypadku, gdy nie chcesz dodawać żadnych opcji montowania obniżających wydajność.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.