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

Am 10.10.21 um 05:52 schrieb Alan Somers:
> On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem <rmacklem@uoguelph.ca> 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.

This is not entirely true: ZFS supports reservations and it could
thus support the pre-allocation of space that is later "filled".
This reservations would be substracted from the free space sum,
and it would be guaranteed that this free space is available for
the file for which the pre-allocation has been requested.

This would require that the allocate() call recorded the block
range for which an allocation is requested (and for which no
disk blocks are currently allocated) without assignment of any
backing blocks at that time.

Later writes to that range would allocate disk blocks and at the
same time reduce the amount that is reserved and remove that range
(that is now allocated) from the recorded pre-allocation range.

This would of course require the addition of block ranges that
are reserved but not yet backed by disk blocks to the znode, and
of the total count of blocks reserved for this purpose in addition
to other types of reservations in a separate variable.

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

While I do think that an allocate() operation could be implemented
in ZFS, it is obvious that this does not apply to all possible
fusefs filesystems (which do not even need to support the concept
of an allocation of blocks or ranges).

Regards, STefan