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.
