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

________________________________________
From: Alan Somers <asomers@freebsd.org>
Sent: Saturday, October 9, 2021 11:52 PM
To: Rick Macklem
Cc: FreeBSD Current
Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca


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?

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

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

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