Hi everyone,
I've written a patch to introduce fallocate()/fallocate64() in uclibc.
This is useful for e2fsprogs which now requires fallocate64(). [0]
Before sending the patch, here's some background: e2fsprogs was using a
direct syscall(__NR_fallocate, ...) in e4defrag which was broken [1].
This was removed and replaced by a simple "#error" if fallocate64 is not
available, which it is not in uclibc, although posix_fallocate64 is.
Ironically, e2fsprogs calls fallocate64 in default mode which is
equivalent to posix_fallocate64. I submitted a patch to e2fsprogs to
use posix_fallocate in e4defrag[2]. Ted Ts'o's response was that
they're not equivalent because, according to him, some implementations
of posix_fallocate fall back on brute force zero-ing if the fallocate
syscall is not available. I responded [3], but the issue fell off the
radar.
Rather than pushing in that direction, I thought perhaps uclibc would
benefit from the addition of fallocate/fallocate64. Its a straight
forward extension of what's already there since posix_fallocate syscalls
fallocate with mode=0. We just relax that for fallocate. I didn't add
tests because testing is already there for posix_fallocate. I guess we
could use test for the different modes, but I'm not sure how useful that
might be for testing.
Ref
[0] https://bugs.gentoo.org/show_bug.cgi?id=516988
[1]
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/misc/e4defrag.c?id=58229aaf85d435469e901c974f31ead6d9124166
[2] http://www.spinics.net/lists/linux-ext4/msg44537.html
[3] http://www.spinics.net/lists/linux-ext4/msg44671.html
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc