[PATCH] libc: add fallback for posix_fallocate() when not supported by underlying FS

Anthony G. Basile basile at opensource.dyc.edu
Tue Sep 30 21:21:43 UTC 2014


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


More information about the uClibc mailing list