* 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
