Description of problem:
tail -f doesn't work on panassas file systems
It appears like the current rhel6 coreutils blacklists fs's for which inotify doesn't work. These are mostly network file systems. Unfortunately, panassas's file system isn't listed and so tail -f doesn't work.
886 # if HAVE_FSTATFS && HAVE_STRUCT_STATFS_F_TYPE && defined __linux__
887 struct statfs buf;
888 int err = fstatfs (fd, &buf);
889 if (err != 0)
891 /* On at least linux-2.6.38, fstatfs fails with ENOSYS when FD
892 is open on a pipe. Treat that like a remote file. */
893 if (errno != ENOSYS)
894 error (0, errno, _("cannot determine location of %s. "
895 "reverting to polling"), quote (name));
899 switch (buf.f_type)
901 case S_MAGIC_AFS:
902 case S_MAGIC_CIFS:
903 case S_MAGIC_CODA:
904 case S_MAGIC_FUSEBLK:
$ ./f_type /panfs/scratch
f_type = 0xaad7aaea
Which seems to be PAN_KERNEL_FS_CLIENT_SUPER_MAGIC
Possible resolution likely seems to be to add PAN_KERNEL_FS_CLIENT_SUPER_MAGIC or 0xaad7aaea to tail's logic.
Version-Release number of selected component (if applicable):
coreutils as shipped with RHEL 6.2
Steps to Reproduce:
1. Run tail -f against a file on a panassas file system.
tail -f does not work
tail -f works
Thanks for the heads up.
Is there a definitive source for that PanFS magic number?
I pull new magic numbers for coreutils from linux kernel header files
semi-automatically, and see that one is not yet there.
I've just posted an upstream coreutils patch for that:
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.