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@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@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org