Date: Sun, 10 Oct 2021 05:57:32 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Message-ID: <YQXPR0101MB0968AE9C289D46AC37D48556DDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAOtMX2hyoyLam%2BOY7_hziiX7%2BEP8h2Ca4qiTpkj8suKZnkv68g@mail.gmail.com> References: <YQXPR0101MB0968322C2DEBFAA672FFBC8EDDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2hyoyLam%2BOY7_hziiX7%2BEP8h2Ca4qiTpkj8suKZnkv68g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Somers wrote:=0A= >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:= =0A= >>=0A= >> Hi,=0A= >>=0A= >> I ran into an issue this week during the nfsv4@ietf.org's testing event.= =0A= >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate().=0A= >> ZFS - just return EINVAL for VOP_ALLOCATE().=0A= >>=0A= >> An NFSv4.2 server can either support Allocate or not, but it has to be= =0A= >> for all exported file systems.=0A= >=0A= >That seems like a protocol bug to me. Could this be fixed in a future=0A= >NFS revision?=0A= Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I thin= k=0A= this is now "cast in stone".=0A= =0A= >>=0A= >> This leads me to a couple of questions:=0A= >> - Is there a good reason for not using vop_stdallocate() for ZFS?=0A= >=0A= >Yes. posix_fallocate is supposed to guarantee that subsequent writes=0A= >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write=0A= >file system, cannot possibly guarantee that. See SVN r325320.=0A= However, vop_stdallocate() just does VOP_WRITE()s to the area (with=0A= bytes of data all zeros). Wouldn't that satisfy the criteria?=0A= =0A= >> - Should I try and support both file system types via vop_stdallocate()= =0A= >> or not support Allocate at all?=0A= >=0A= >Since you can't possibly support it for ZFS (not to mention other file=0A= >systems like fusefs) you'll have to not support it at all.=0A= It does sound like not supporting it is the best alternative.=0A= =0A= rick=0A= =0A= >=0A= > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways,= =0A= > such as offset=3D0, len=3D1. Why, I have no idea?=0A= >=0A= > Thanks in advance for any comments, rick=0A= >=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB0968AE9C289D46AC37D48556DDB49>