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

Alan Somers wrote:
[stuff snipped]
>Rick Macklem wrote:
> >Alan Somers wrote:
> > >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?
>
> No.  It works for UFS, which is an overwriting file system.  But for
> ZFS, when the user comes back later to rewrite those same offsets, ZFS
> will actually allocate new LBAs for them.
Eighto. I get it now.

Looks like I must disable it in the server, unless there is a way to enable
it on a per file system basis (which I don not believe is the case for NFSv4.2,
although that isn't completely clear from the RFC, which says each operation
is optional, but does not mention "per file system").

Thanks everyone, for your replies, rick

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