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

Reply via email to