* Christoph Hellwig: > On Mon, Jul 29, 2024 at 07:57:54PM +0200, Florian Weimer wrote: >> When does the kernel return EOPNOTSUPP these days? > > In common code whenever the file system does not implement the > fallocate file operation, and various file systems can also > return it from inside the method if the feature is not actually > supported for the particular file system or file it is called on. > >> Last time I looked at this I concluded that it does not make sense to >> push this write loop from glibc to the applications. That's what would >> happen if we had a new version of posix_fallocate that didn't do those >> writes. We also updated the manual: > > That assumes that the loop is the right thing to do for file systems not > 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. 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. > 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. Thanks, Florian
