Re: posix_fallocate behavior in glibc

[Florian Weimer <fweimer@redhat.com>]

* Christoph Hellwig:

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

It's more about a file copying tool doing this by default on behalf of
the users (perhaps Midnight Commander?).  If I recall, posix_fallocate
is also used by file-sharing clients, and those might be used with
external storage media that have older file systems.

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

Why doesn't the kernel perform allocation in these cases?  There doesn't
seem to be a file-system-specific reason why it's impossible to do.

At the very least, we should have a variant of ftruncate that never
truncates, likely under the fallocate umbrella.  It seems that that's
how posix_fallocate is used sometimes, for avoiding SIGBUS with mmap.
To these use cases, whether extents are allocated or not does not
matter.

>> 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 removed the fallback code from glibc today, it would just be
EOPNOTSUPP that leaks to applications, so it's structurally the same
issue.  The error codes that glibc's posix_fallocate can produce are all
different (unless write on the file fails with EOPNOTSUPP in the kernel,
but that would be quite unexpected).  EOPNOTSUPP would be equally
surprising.

Thanks,
Florian