[nfsv4] Re: FATTR4_MIN_HOLE_SIZE, and sparse file minimum requirement RFC?

[Thomas Haynes <[e-mail]>]

> On Mar 2, 2026, at 1:11 AM, Cedric Blancher <[e-mail]> wrote:
> 
> On Sun, 1 Mar 2026 at 17:40, Thomas Haynes <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>> On Mar 1, 2026, at 4:04 AM, David Noveck <[e-mail]> wrote:
>> 
>> 
>> 
>> On Sunday, March 1, 2026, Cedric Blancher <[e-mail]> wrote:
>>> 
>>> Good morning!
>>> 
>>> 1. IMO it may be nice to get a per-fs FATTR4_MIN_HOLE_SIZE attribute
>>> to provide a byte-size value for pathconf() _PC_MIN_HOLE_SIZE, .
>> 
>> 
>> Probably,  but if you think we need one, aa I suspect you do, you will have to at least propose that we do that and may have to do more.
> 
> First I wanted feedback, and then I'll do a proposal.
> 
>> 
>>> to
>>> define the "minimum hole size" for sparse files.
>> 
>> 
>> I don't know much about sparse file support  but I am not clear as to limits based on a brief scan of RFC7862.
> 
> https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html
> 3.347ff, but I am mostly interested in two things:
> 1. Getting a proper value for _PC_MIN_HOLE_SIZE from the filesystem
> exported by the NFS server
> 2. Detecting early (before opening a file) whether the NFSv4.2
> extensions SEEK, ALLOCATE and DEALLOCATE are supported by the NFS
> server and can be implemented on that exported filesystem
> 
> [1] is often different from the default block size, typically smaller
> (sometimes by factor 8, e.g. 4096 byte block size --> 512 byte minhole
> size, or sometimes by factor 64; or sometimes much larger, say 128k
> for 4k block size)
> 
> Question is whether FATTR4_MIN_HOLE_SIZE MUST only be supported IF
> NFSv4.2 extensions SEEK, ALLOCATE and DEALLOCATE are available, or a
> separate attribute with a bitmap4 is used to set a bit or NFS4 op
> supported.
> 
>> 
>>> 
>>> 
>>> (this can be different
>>> from the (logical) block size).
>> 
>> 
>> OK.    But I'm  not clear about the concept of block size in  NFSv4.  RFC7862 uses BLOCK_SIZE but I couldn't find a definition of how this value was determined and used.  Was not in RFC8881 either.  What am I missing?
> 
> I thought NFSv4.x avoids setting a global "block size", as modern
> filesystems can use multiple block sizes, or the block size can change
> if the file is moved around in a HSM.

Take the use of the word BLOCK_SIZE as meaning the size of the blocks on a given filesystem. It has nothing to do with the protocol. It is used purely to illustrate an example.


> 
> FATTR4_MIN_HOLE_SIZE however is different, it does not implement
> "block size semantics", it only implements a hint for the minimum size
> of sparse file holes.
> 
>> And that is not possible in NFSv4.2 - there are existing implementations of NFSv.4.2 which support these operations and you cannot retroactively change the requirements on them.
> 
> We do not wish to change NFSv4.2, we want a small extension to map
> POSIX _PC_MIN_HOLE_SIZE, and maybe a solution to detect which NFS ops
> are supported for a given NFS server and exported filesystem.
> 

That does not match up with your repeated use of the word MUST.


> Ced
> -- 
> Cedric Blancher <[e-mail] <mailto:[e-mail]>>
> [https://plus.google.com/u/0/+CedricBlancher/]
> Institute Pasteur
> 
> _______________________________________________
> nfsv4 mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>