Dlaczego zdarzenia inotify różnią się w przypadku montażu NFS?

Jakiś czas temu zauważyłem, że zdarzenia zgłaszane przez inotify różnią się, gdy plik jest zapisywany na wierzchowcu NFS w porównaniu z lokalnym systemem plików.

Czy bazowy VFS nie powinien zapewniać jednolitego widoku operacji na plikach?

Poniżej znajduje się ślad zapisywania pliku przez VIM w Debian 7.1 (Linux 3.2)

Na montażu NFS:

wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 16 (IN_CLOSE_NOWRITE)
wd=1 mask = 2048 (IN_MOVE_SELF)
wd=1 mask = 4 (IN_ATTRIB)
wd=1 mask = 1024 (IN_DELETE_SELF)
wd=1 mask = 32768 )

W lokalnym systemie plików

wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 16 (IN_CLOSE_NOWRITE)
wd=1 mask = 2 (IN_MODIFY)
wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 8 (IN_CLOSE_WRITE)
wd=1 mask = 4 (IN_ATTRIB)

Zapisanie pliku za pomocą EMACS ujawnia również inne zachowanie

Na montażu NFS:

wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 16 (IN_CLOSE_NOWRITE)
wd=1 mask = 2048 (IN_MOVE_SELF)

W lokalnym systemie plików:

wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 16 (IN_CLOSE_NOWRITE)
wd=1 mask = 2 (IN_MODIFY)
wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 2 (IN_MODIFY)
wd=1 mask = 8 (IN_CLOSE_WRITE)

Te testy zostały uruchomione za pomocą inotify-touch.c

inotify wsparcie NFS?

Rozglądając się po sieci, wydaje się, że inotify może obsługiwać NFS, ale w bardzo ograniczony sposób.

Powód jest wyjaśniony w tym pytaniu i odpowiedziach StackOverflow zatytułowanym: inotify with NFS .

fragment zaakceptowanej odpowiedzi

Do działania inotify wymaga wsparcia jądra. Gdy aplikacja śledzi katalog, prosi jądro o poinformowanie go o wystąpieniu tych zmian. Kiedy nastąpi zmiana, oprócz zapisania tych zmian na dysku, jądro powiadamia również proces oglądania.

Na zdalnym komputerze NFS zmiana nie jest widoczna dla jądra; dzieje się to całkowicie zdalnie. NFS poprzedza inotify i nie ma wsparcia na poziomie sieci w NFS ani w żadnym innym równoważnym.

Poszukuję trochę więcej, jeśli zajrzysz do inotify FAQ

P: Czy mogę oglądać sysfs (procfs, nfs ...)?

Mówiąc prosto: tak, ale z pewnymi ograniczeniami. Ograniczenia te różnią się w zależności od wersji jądra i zwykle stają się mniejsze. Proszę przeczytać informacje o poszczególnych systemach plików.

Czy to jest obsługiwane?

Myślę, że ostatecznie to, czego doświadczasz, to to, że NFS nie zapewnia jabłkom odpowiedników wszystkich tych samych funkcji, co lokalnie montowane systemy plików.

Na przykład z wątku linuksowego nfs :

• CIFS ma wbudowane funkcje powiadomień (blokuje)
• NFS zapewnia „dzierżawę” dla powiadomienia

Chodzi o to, że alternatywny system plików, taki jak CIFS i NFS, oferuje bardzo proste, jeśli jakakolwiek obsługa bezpośrednio do inotify.

Stan NFS v4

fragment artykułu IBM o stanie NFS v4

NFS w wersji 4 zawiera protokół umożliwiający klientowi ustalenie lub przywrócenie stanu oraz powiązanie własności kolejnych operacji stanowych serwera z wcześniej ustalonymi stanami. Aby rozwiązać problem z nieobecnym klientem, klient NFS w wersji 4 musi rutynowo odświeżać stan w czasie dzierżawy określonym przez serwer. Po upływie czasu dzierżawy serwer może zwolnić zasoby dla klienta i udostępnić je innym aplikacjom.

• Klient uzyskuje określony przez serwer atrybut limitu czasu dzierżawy, wykonując operację getattr. getattr nie jest operacją stanową, dlatego nie wymaga ustanowienia wcześniejszego stanu. Operacja getattr może poprzedzać operację setclientid lub setclientid_confirm.
• Informacje na temat ustawiania i dostrajania okresów dzierżawy można znaleźć w atrybucie witryny dzierżawy serwera NFS. *