generic/035 checks that a file/directory that is open but
has been overwritten will have nlink = 0. This test fails for NFS files
because in order to properly implement remove-on-last-close NFS uses a
process called silly-renaming where the file is renamed on the server.
Silly-renaming isn’t used for directories, so when an open directory is
deleted, operations on that directory return -ESTALE.
generic/087 checks that setting the file access and modification times to
the current time and to a specific timestamp is allowed when expected. This
test failes (at least on Fedora 24) because it uses uid 99 (nobody) instead
of uid 65534 (nfsnobody).
We can easily fix this up by explicitly setting our anonuid and anongid
back to uid 99 when setting up the test’s exports:
generic/285 tests for the proper functioning of SEEK_HOLE and SEEK_DATA,
however it failes on NFS with an exported xfs filesystem because
src/seek_sanity_test.c uses an allocation unit size based on the value of
the NFS mount’s st_blksize. That size is typically much larger than the
allocation unit of the underlying filesystem, and so triggers preallocation
strategies in XFS that cause the test to fail. There’s a pending patch to
discover the correct allocation unit size
generic/294 checks for proper return codes for creating files on
So creating a directory on ro returns EROFS insteand of EEXIST.
generic/306 checks for proper behavior on read-only mounts.. but NFS fails
this. It appears that a remount,ro of the scratch filesystem also causes
the test filesystem to switch to ro if both filesystems are exported with
the same fsid.
After a quick look, it seems the superblocks are shared as MS_RDONLY is in
NFS_MS_MASK. The behavior isn’t reproduced with the nosharecache option.
Also, explicitly setting separate fsid for each export should clear up the
problem as well.
Setting separate fsid values is only going to work if the exported
directories on the same filesystem are exported from the v4 root. This is
because knfsd’s “if (nfsd_mountpoint(dentry, exp))” is only flagging to look
up an export on the v4 root during LOOKUP.
So, to sum up, fixing generic/306 means either mounting with nosharecache,
or separate fsid values on exports on fsid=0 if using the same filesystem
for the export.
Well, this is a blockdev test. I am not exactly sure why it is failing on my
test machine, probably something to do with virtual hardware. It fails like
I think it’s probably safe to just exclude any of the blockdev tests for our
purposes. That ends up excluding only three tests.