Re: tail + inotify over nfs

[Jim Meyering]

Pádraig Brady wrote:
> I've just noticed that `tail -f` will not work over NFS
> as changes on the remote system will not go through
> the local VFS and so will not be noticed by inotify.

Ouch.
Good catch.

> Testing with `tail -s.1 ---disable-inotify` does get the
> changes noticed, albeit after a delay of 3s on my setup.

Odd that it would take so long.

> So what to do? I suppose we could statfs("filename")

Yes, I think something like that is required.
For even less impact, call fstatfs on the file descriptor.  It might be
worth factoring out or writing something similar to the device-to-FS-type
mapping code used in fts.c (link_count_optimize_ok).  Then, when tailing
many files and when polling frequently, there would be no significant
impact on performance, since there'd be only one added syscall per device,
not per file or per open.

> and then use polling for CIFS CODA FUSECTL? LUSTRE NFS SMB.
> I wonder should lib/mountlist.c::read_file_system_list()
> be updated as it only considers NFS, SMB and CIFS as remote?

> Also I wonder why GFS is not in the fs.h list?

That list is now mostly generated from a combination of
man page info and <linux/magic.h>.  See the rule in src/Makefile.am.
I just did "make -C src fs-magic-compare" and noticed a new addition
for S_MAGIC_SOCKFS on rawhide, so added it.

If you find any missing magic numbers, you're welcome to add them.
Bonus points if you can further automate detection, when new types appear.