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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
