Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd
- Reply: Warner Losh : "Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd"
- Reply: Alan Somers : "Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd"
- Reply: Willem Jan Withagen via freebsd-current : "Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd"
- In reply to: Alan Somers : "Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 10 Oct 2021 05:57:32 UTC
Alan Somers wrote: >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem <rmacklem@uoguelph.ca> wrote: >> >> Hi, >> >> I ran into an issue this week during the nfsv4@ietf.org's testing event. >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). >> ZFS - just return EINVAL for VOP_ALLOCATE(). >> >> An NFSv4.2 server can either support Allocate or not, but it has to be >> for all exported file systems. > >That seems like a protocol bug to me. Could this be fixed in a future >NFS revision? Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I think this is now "cast in stone". >> >> This leads me to a couple of questions: >> - Is there a good reason for not using vop_stdallocate() for ZFS? > >Yes. posix_fallocate is supposed to guarantee that subsequent writes >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write >file system, cannot possibly guarantee that. See SVN r325320. However, vop_stdallocate() just does VOP_WRITE()s to the area (with bytes of data all zeros). Wouldn't that satisfy the criteria? >> - Should I try and support both file system types via vop_stdallocate() >> or not support Allocate at all? > >Since you can't possibly support it for ZFS (not to mention other file >systems like fusefs) you'll have to not support it at all. It does sound like not supporting it is the best alternative. rick > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > such as offset=0, len=1. Why, I have no idea? > > Thanks in advance for any comments, rick >