On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem <rmack...@uoguelph.ca> wrote: > > Hi, > > I ran into an issue this week during the nf...@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 >
