On Mon, Jul 29, 2024 at 08:52:00PM +0200, Florian Weimer wrote:
> * 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.
Huh. EOPNOTSUPP. is explicitly stated as a valid "not implemented in
kernel or userspace" error return in the man page.
EOPNOTSUPP
The filesystem containing the file referred to by fd does
not support this operation. This error code can be returned
by C libraries that don't perform the emulation shown in
NOTES, such as musl libc.
Hence libc-independent applications already have to handle
EOPNOTSUPP being returned by posix_fallocate() and implement their
own fallback if they really need it.
Having documented behaviour of "glibc does emulation so badly you
need to work around it" is really not a strong position from which
to advocate that the kernel needs to change behaviour....
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
