Re: [PATCH xfstests] generic/035: Override output for NFS testing

[bfields@fieldses.org (J. Bruce Fields)]

On Tue, Apr 03, 2018 at 08:36:35AM -0400, Benjamin Coddington wrote:
> On 3 Apr 2018, at 8:25, Christoph Hellwig wrote:
> 
> > On Tue, Apr 03, 2018 at 08:10:36AM -0400, Benjamin Coddington wrote:
> >> No, having nlink == 1 is not a bug and we should expect that behavior, the
> >> same with the -ESTALE return for a directory.  This is true, at least, for
> >> the linux client.
> >
> > In terms of Linux semantics is plain and simple is a bug.  It is an
> > expected bug in NFS, but that doesn't make it correct.
> 
> Ok yes.  I'd still like to test for it, since it's possible we can get this
> wrong.

In the regular file case this is fixable with current protocol[1].

If/when we fix this then we'll want a test like this one to verify the
fix.  So I think I'm won over to Christoph's point of view here.

Agreed that it'd be nice to have expected failures reported separately
somehow, though, as sorting through this kind of thing is an obstacle to
new NFS developers starting with xfstests.

--b.

[1] Grep for "OPEN4_RESULT_PRESERVE_UNLINKED" in RFC 5661.  NFSv4 opens
can already hold a reference to an unlinked file, the remaining work is
to figure out how to persist that across server reboot.  Maybe we'd do a
sillyrename server-side into a hidden directory and fix up nlink to hide
the extra link in this case.  Then we'd need to teach the client to stop
doing sillyrename when the PRESERVE_UNLINKED flag is set.