On Mon, Jul 29, 2024 at 08:52:00PM +0200, Florian Weimer wrote: > > supporting fallocate. That's is generally the wrong thing to do, and > > spectacularly wrong for file systems that write out of place. > > In this case, the file system could return another error code besides > EOPNOTSUPP. What error code would that be and how do applications know about it? > There's a difference between “no one bothered to implement > this” and “this can't be implemented correctly”, and it could be > reflected in the error code. posix_fallocate can't be correctly implemented in userspace, which is part of the problem. > > The applications might not know about glibc/Linux implementation details > > and expect posix_fallocate to either fail if can't be supported or > > actually give the guarantees it is supposed to provide, which this > > "fallback" doesn't actually do for the not entirely uncommon case of a > > file system that is writing out of place. > > I think people are aware that with thin provisioning and whatnot, even a > successful fallocate call doesn't mean that there's sufficient space to > complete the actual write. With a correctly implemented fallocate the guarantee in the standard actually work properly. Even if the underlying block device is thinly provisioned and makes a write fail due to lack of space in the block device this will actually shut down the file system entirely but not return -ENOSPC.
