Re: posix_fallocate behavior in glibc

[Christoph Hellwig <hch@lst.de>]

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.