Date: Sun, 10 Oct 2021 13:57:07 +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: <YQXPR0101MB096898D52B2034F530F788A2DDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAOtMX2j0gM-ujuK2G-%2Bzi9_eNtECy3CNv-ujZtajWgr3gvPMrg@mail.gmail.com> References: <YQXPR0101MB0968322C2DEBFAA672FFBC8EDDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2hyoyLam%2BOY7_hziiX7%2BEP8h2Ca4qiTpkj8suKZnkv68g@mail.gmail.com> <YQXPR0101MB0968AE9C289D46AC37D48556DDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2j0gM-ujuK2G-%2Bzi9_eNtECy3CNv-ujZtajWgr3gvPMrg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Somers wrote:=0A= [stuff snipped]=0A= >Rick Macklem wrote:=0A= > >Alan Somers wrote:=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= > No. It works for UFS, which is an overwriting file system. But for=0A= > ZFS, when the user comes back later to rewrite those same offsets, ZFS=0A= > will actually allocate new LBAs for them.=0A= Eighto. I get it now.=0A= =0A= Looks like I must disable it in the server, unless there is a way to enable= =0A= it on a per file system basis (which I don not believe is the case for NFSv= 4.2,=0A= although that isn't completely clear from the RFC, which says each operatio= n=0A= is optional, but does not mention "per file system").=0A= =0A= Thanks everyone, for your replies, rick=0A= =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 way= s,=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?YQXPR0101MB096898D52B2034F530F788A2DDB49>