Re: posix_fallocate behavior in glibc

[Christoph Hellwig <hch@lst.de>]

On Tue, Jul 30, 2024 at 09:11:17AM -0700, Paul Eggert wrote:
> It would help glibc distinguish the following cases:
>
> A. file systems whose internal structure supports the semantics of 
> posix_fallocate, and where user-mode code can approximate those semantics 
> by writing zeros, but where that feature has not been implemented in the 
> kernel's file system code so the system call currently fails with 
> EOPNOTSUPP.
>
> B. file systems whose internal structure cannot support the semantics of 
> posix_fallocate and you cannot approximate them, and where the system call 
> currently fails with EOPNOTSUPP.

As mentioned earlier in the thread case a) are basically legacy / foreign
OS compatibility file systems (minix, sysfs, hfs/hfsplus).  They are
probably not something that people actually use posix_fallocate on.
The only relevant exception is probably ext4 in ext2/ext3 mode, where
the latter might still have users left running real workloads on it
and not using it for usb disks or VM images.

> Florian is proposing that different error numbers be returned for (A) vs 
> (B) so that glibc posix_fallocate can treat the cases differently.

The problem with a new error code is that it will leak out to the
application when using a new kernel and an old glibc.  If we want to skin
the cat that way a better way might be to expose this kind of information
through a statx flag or a similar interface.