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. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
