Re: [PATCH pynfs] Allow server to reject maximum commit offsets

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Feb 09, 2010 at 05:45:06PM -0500, Peter Staubach wrote:
> J. Bruce Fields wrote:
> > On Tue, Feb 09, 2010 at 05:28:52PM -0500, Peter Staubach wrote:
> >> J. Bruce Fields wrote:
> >>> From: J. Bruce Fields <bfields@citi.umich.edu>
> >>>
> >>> These two tests insist that a server must accept commits with offset
> >>> 2^64-1 and 2^64-2.  I can find no justification in the spec for this
> >>> requirement.
> >>>
> >>> The linux server was recently changed to reject (with INVAL) offsets
> >>> over 2^63-1, which is the maximum that the vfs commit routine can
> >>> accept.  That behavior is consistent with the NFSv3 commit
> >>> implementation and with the NFSv4 write implementation.
> >>>
> >> I guess that I am missing something.  At least the NFSv3
> >> COMMIT operation takes an unsigned 64 bit quantity.  That
> >> would seem to make the test correct, would it not?
> > 
> > Yes, it's an unsigned 64 bit integer, but so what: there's no rule that
> > says the server has to return NFS4ERR_OK to any operation for which all
> > the arguments are valid xdr.
> > 
> > And just because the protocol allows 64-bit offsets doesn't mean every
> > server and filesystem is going to support the full range.
> > 
> 
> No, that's certainly true.  However, you are tailoring the
> testsuite to a Linux specific implementation, which strikes
> me as vaguely not so good.  What if you just commented out
> the tests, with a comment indicating that the Linux server
> can not handle the full 64 bits of range, instead of
> deleting them completely?

The tests are primarily meant to test protocol conformance.  So they
shouldn't be reporting failures on conforming behavior.

Perhaps it would also be interesting to run the tests in a mode which
probes and summarizes server characteristics (maximum supported offset,
supported features, etc.), but that's a job for another day.

--b.