The build fails upon trying to compile misc/e4defag: make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/var/tmp/portage/sys-fs/e2fsprogs-1.42.10/work/e2fsprogs-1.42.10/debugfs' making all in misc make[2]: Entering directory `/var/tmp/portage/sys-fs/e2fsprogs-1.42.10/work/e2fsprogs-1.42.10/misc' x86_64-gentoo-linux-uclibc-gcc -c -I. -I../lib -I../lib -D_GNU_SOURCE -O2 -pipe e4defrag.c -o e4defrag.o e4defrag.c:201:2: error: #error fallocate64 not available! make[2]: *** [e4defrag.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/sys-fs/e2fsprogs-1.42.10/work/e2fsprogs-1.42.10/misc' make[1]: *** [all-progs-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sys-fs/e2fsprogs-1.42.10/work/e2fsprogs-1.42.10' make: *** [all] Error 2 The code intentionally commits suicide with #ifndef HAVE_FALLOCATE64 #error fallocate64 not available! #endif /* ! HAVE_FALLOCATE64 */ Indeed, uclibc doesn't have fallocate64() but it *does* have posix_fallocate64(). Since fallocate64() is called with mode = 0, the behaviour of the two should be the same. man 2 fallocate for reference. We could either port fallocate/fallocate64() to uclibc or make e2fsprogs more posix-ish. I blame e2fsprogs. The patch is easy enough. Patching just the C file for now (eventually we need to get the build system checking for all the right stuff): --- e4defrag.c.orig 2014-07-12 18:23:07.455118894 +0000 +++ e4defrag.c 2014-07-12 18:23:30.828248798 +0000 @@ -197,10 +197,6 @@ #error sync_file_range not available! #endif /* ! HAVE_SYNC_FILE_RANGE */ -#ifndef HAVE_FALLOCATE64 -#error fallocate64 not available! -#endif /* ! HAVE_FALLOCATE64 */ - /* * get_mount_point() - Get device's mount point. * @@ -1552,7 +1548,7 @@ /* Allocate space for donor inode */ orig_group_tmp = orig_group_head; do { - ret = fallocate64(donor_fd, 0, + ret = posix_fallocate64(donor_fd, (loff_t)orig_group_tmp->start->data.logical * block_size, (loff_t)orig_group_tmp->len * block_size); if (ret < 0) { I will be masking =sys-fs/e2fsprogs-1.42.10 on uclibc profiles until this is fixed. Reproducible: Always
Created attachment 380646 [details, diff] Use posix_fallocate64() if fallocate64() is unavailable This patch applies against git/HEAD: git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git I'll send it upstream.
(In reply to Anthony Basile from comment #1) > Created attachment 380646 [details, diff] [details, diff] > Use posix_fallocate64() if fallocate64() is unavailable > > This patch applies against git/HEAD: > > git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git > > I'll send it upstream. Hmm ... not sure where upstream is. I tried to just email it directly to Ts'o
Created attachment 381958 [details, diff] Use posix_fallocate64() if fallocate64() is unavailable Updated version of the patch emailed to linux-ext4@vger.kernel.org. See http://www.spinics.net/lists/linux-ext4/msg44537.html for any discussions.
looks reasonable to me ... i might even suggest they should only use posix_fallocate considering that func is in POSIX and fallocate is not
(In reply to SpanKY from comment #4) > looks reasonable to me ... i might even suggest they should only use > posix_fallocate considering that func is in POSIX and fallocate is not Here's Ts'o response and then mine to him: http://www.spinics.net/lists/linux-ext4/msg44671.html His concern is that some implementations of posix_fallocate() just fall back on brute force zero-ing. At least for uclibc and musl this is not the case. I don't know of any libc that does that and doesn't just syscall fallocate. Anyhow, if the kernel doesn't provide the syscall, how else can you implement fallocate except by brute force? I'm not sure what else to say to him.
(In reply to Anthony Basile from comment #5) > (In reply to SpanKY from comment #4) > > looks reasonable to me ... i might even suggest they should only use > > posix_fallocate considering that func is in POSIX and fallocate is not > > Here's Ts'o response and then mine to him: > > http://www.spinics.net/lists/linux-ext4/msg44671.html > > His concern is that some implementations of posix_fallocate() just fall back > on brute force zero-ing. At least for uclibc and musl this is not the case. > I don't know of any libc that does that and doesn't just syscall fallocate. > > Anyhow, if the kernel doesn't provide the syscall, how else can you > implement fallocate except by brute force? I'm not sure what else to say to > him. Rather than fight ext4 upstream, I've gotten fallocate/fallocate64 into uclibc. The commit is at http://git.uclibc.org/uClibc/commit/?id=33a12b5540b8abbc4ee0ecb3a51912b3c7868517 It still needs to be backported to 0.9.33. It doesn't apply cleanly. I can prepare a backport patch but how do I get it into 0.9.33?
(In reply to Anthony Basile from comment #6) > > It still needs to be backported to 0.9.33. It doesn't apply cleanly. I can > prepare a backport patch but how do I get it into 0.9.33? I emailed the backport to the list: http://lists.uclibc.org/pipermail/uclibc/2014-September/048621.html I have yet to check how it applies against the current uClibc-0.9.33.2-patches-14.tar.bz.
(In reply to Anthony Basile from comment #7) > (In reply to Anthony Basile from comment #6) > > > > It still needs to be backported to 0.9.33. It doesn't apply cleanly. I can > > prepare a backport patch but how do I get it into 0.9.33? > > I emailed the backport to the list: > > http://lists.uclibc.org/pipermail/uclibc/2014-September/048621.html > > I have yet to check how it applies against the current > uClibc-0.9.33.2-patches-14.tar.bz. ping. Can I get this in the next patchset.
@mike, I added the needed patches to the patchset in cvs, rolled a patch using make-tarball.sh and put it on woodpecker's /space/distfile-local and in my dev space at ~blueness/uclibc. Its PATCH_VER="15". I also bumped the ebuild to 0.9.33.2-r13. I'd like to stabilize this in about 1-2 months because it is blocking progress on e2fsprogs on all my uclibc builds. Please let me know if I did anything wrong.
>=uclibc-0.9.33.2-r14 is now stable on all but m68k sh and sparc. All versions of e2fsprogs up to the latest 1.42.12 build fine. I'm going to close this bug in favor of but #539226 which is the final stablereq for m68k sh and sparc.
