Date: Sun, 10 Oct 2021 22:15:44 +0200 From: Willem Jan Withagen via freebsd-current <freebsd-current@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca>, 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: <bcb12b93-0f79-4e2a-0f5b-71444820984f@digiware.nl> In-Reply-To: <YQXPR0101MB0968AE9C289D46AC37D48556DDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <YQXPR0101MB0968322C2DEBFAA672FFBC8EDDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2hyoyLam%2BOY7_hziiX7%2BEP8h2Ca4qiTpkj8suKZnkv68g@mail.gmail.com> <YQXPR0101MB0968AE9C289D46AC37D48556DDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-10-2021 07:57, Rick Macklem wrote: > >>> 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? > I had the same problem in Ceph, where a guaranteed writable space is required for keeping a log of modifications to the system. Not having this space might case loss of data. Writing al zero's is probably even worse on filesystems that have compression set. Almost nothing is allocated, and so no guarantee at all. Next trick wass to write random data, but then you run into the problem signaled by Alan and Warner. New writes will need free space, since the CoW nature. Solution was to actually create a specific zpool just for this. But that will not help you with NFS 4.2 I guess --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bcb12b93-0f79-4e2a-0f5b-71444820984f>