e2fsprogs 1.42.11 and above fails to build on uclibc

[Waldemar Brodkorb]

Hi Anthony,
Anthony G. Basile wrote,

> 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.

As you working on extending fallocate functions, would it be
possible to fix the test case tst-posix_fallocate64?

It would be nice to have this fixed, before adding changes to
posix_fallocate64 files, to see if your patch adds any regression
to the existing codebase. What do you think?

See the test failures here:
http://openadk.org/test/

May be it is just a simple bug, have not looked into this, yet.
 
best regards
 Waldemar