7:02 a.m.
According to my reading, either 0 or INT64_MAX should work fine, since
locking beyond the end of the file is fine.
Daniel
On 04/25/2018 05:22 AM, Malahal Naineni wrote:
knfsd seems to send EINVAL based on a quick look at the code.
Assuming
it as end of file (0) may work, but will have to check if all cthon
tests pass!
On Wed, Apr 25, 2018 at 4:26 AM, Frank Filz <ffilzlnx(a)mindspring.com
<mailto:ffilzlnx@mindspring.com>> wrote:
In NFS v4 and NLM, the lock length type is uint64_t. In many of our
supported filesystems, lock length is defined as off_t or off64_t
which are signed quantities.____
__ __
The Windows NFS v3 client at least has demonstrated issuing a lock
length of UINT64_MAX.____
__ __
FSAL_GPFS returns an error if lock length is greater than LONG_MAX.____
__ __
FSAL_GLUSTER and FSAL_VFS stuff the value into an off64_t, and then
complains about lock length being less than zero.____
__ __
I’m not sure about the other FSALs.____
__ __
Returning an error ends up making Windows applications not work
which is not ideal.____
__ __
I think it might be best if inside the FSAL, we just quietly reduce
lock length to a valid value, though I don’t know if that should be:____
__ __
0 – indicating end of file____
INT64_MAX – largest possible length____
INT64_MAX – offset – so end of lock doesn’t exceed INT64_MAX____
____
Does anyone have any thoughts?____
__ __
Frank____
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org