Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd

On Sat, Oct 9, 2021, 11:58 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:

> 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?
>

Since it is log based, that would make it worse. The blocks aren't
instantly reclaimed when marked invalid. So you'd need storage for both and
the 0d blocks could cause a resource shortage when the real writes come in.
ZFS doesn't have a reservation system to reserve blocks in the log for a
given file...

Warner

>> - 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
> >
>
>