On 09/29/14 13:39, Olivier Blin wrote:
On 09/29/14 18:42, Rich Felker wrote:
On Mon, Sep 29, 2014 at 04:43:32PM +0200, Olivier Blin wrote:
> EOPNOTSUPP is not a valid error code for posix_fallocate(), the
> implementation should have a fallback when the underlying filesystem
> does not support fallocate().
>
> This is especially useful when using posix_fallocate() on tmpfs with
> kernels older than 3.5, for which there was no fallocate support.
>
> This copies the implementation of the internal fallback from glibc,
> with a few adaptations for internals symbols.
This code is dangerous (has race conditions that cause file
corruption) and should not be added. See the bug report for the
corresponding code in glibc:
https://sourceware.org/bugzilla/show_bug.cgi?id=15661
Rich
Indeed, this is dangerous.
According to the specification of posix_fallocate(), there does not seem
to be an appropriate error code to return when the filesystem driver
does not natively support fallocate().
In this case, the libc should probably provide a fallback implementation.
Why can't there be an implementation specific error message here since
the specs are silent on the issue? I see no problem with returning
ENOTSUP even though its not specified in [1].
Users of posix_fallocate() do not expect it to fail if the FS does not
support fallocate().
The specs don't guarantee that. A better approach would be to check for
the errors specified in [1], in say a switch-case, and then have a
default which is some other "unspecified" error.
See for example the usage in wayland:
http://cgit.freedesktop.org/wayland/wayland/tree/cursor/os-compatibility.c?h=1.6&id=1.6.0#n79
Sounds like a bug in wayland. glibc might be creating some unreasonable
expectations.
To have a better fallback, I don't see a way to avoid the extra child
process either, since we can only do the atomic compare-and-swap through
mmap.
Does anyone have a better suggestion to implement the fallback?
I'm not sure there is any good fallback if the fallocate syscall is not
available. Again, it seems reasonable to me to just let it fail rather
than trying to implement it via some brute force.
Ref.
[1]
http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
