Perché gli eventi inotify sono diversi su un mount NFS?

Qualche tempo fa ho notato che gli eventi segnalati da inotify sono diversi quando il file viene salvato su un mount NFS rispetto a un file system locale.

Il VFS sottostante non dovrebbe fornire una visione uniforme delle operazioni sui file?

Quella che segue è la traccia di VIM che salva un file in Debian 7.1 (Linux 3.2)

Su un mount 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 )

Su un file system locale

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)

Il salvataggio di un file con EMACS rivela anche diversi beahvior

Su un mount NFS:

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

Su un file system locale:

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)

Questi test verranno eseguiti con inotify-touch.c

inotify supporto NFS?

Guardando intorno alla rete sembrerebbe che inotify possa supportare NFS ma in modo molto limitato.

Il motivo è spiegato in queste domande e risposte StackOverflow intitolate: inotify with NFS .

estratto dalla risposta accettata

inotify richiede il supporto del kernel per funzionare. Quando un'applicazione traccia una directory, chiede al kernel di informarla quando si verificano tali cambiamenti. Quando si verifica la modifica, oltre a scrivere quelle modifiche su disco, il kernel notifica anche il processo di osservazione.

Su una macchina NFS remota, la modifica non è visibile al kernel; succede interamente da remoto. NFS è precedente a inotify e non esiste alcun supporto a livello di rete in NFS o qualcosa di equivalente.

Ricerca un po 'di più se si guarda nelle FAQ di inotify

Q: Posso guardare sysfs (procfs, nfs ...)?

Detto semplicemente: sì, ma con alcune limitazioni. Queste limitazioni variano tra le versioni del kernel e tendono a ridursi. Si prega di leggere informazioni su particolari filesystem.

Quindi è supportato?

Penso che in definitiva ciò che stai vivendo sia che NFS non fornisce una mela alle mele equivalente delle stesse funzionalità dei filesystem montati localmente.

Ad esempio da un thread Linux nfs :

• CIFS ha funzionalità di notifica integrate (oplock)
• NFS fornisce "contratti di locazione" per la notifica

Il punto qui è che un filesystem alternativo come CIFS e NFS offre un supporto molto semplice, se non addirittura diretto, per inotificare.

Stato NFS v4

estratto dall'articolo IBM sullo stato NFS v4

NFS versione 4 fornisce un protocollo per il client per stabilire o ristabilire lo stato e associa la proprietà delle successive operazioni stateful del server agli stati precedentemente stabiliti. Per risolvere il problema del client assente, il client NFS versione 4 deve aggiornare periodicamente lo stato entro il tempo di leasing specificato dal server. Al timeout del leasing, il server può rilasciare risorse per il client e renderle disponibili per altre applicazioni.

• Un client ottiene l'attributo di timeout del lease specificato dal server eseguendo un'operazione getattr. getattr non è un'operazione con stato, quindi non richiede lo stato precedente da stabilire. Un'operazione getattr può precedere un'operazione setclientid o setclientid_confirm.
• Fare riferimento all'attributo del leasetime del server NFS per l'impostazione e l'ottimizzazione dei periodi di leasing. *