GNU Grep 2.13 causes build failure in glib on ZFS #829

Closed
ryao opened this Issue Jul 13, 2012 · 5 comments

Comments

Projects
None yet
4 participants
Member

ryao commented Jul 13, 2012

A failure involving sparse files occurs when building glib when using GNU Grep 2.13. There is an open bug report on this in the Gentoo bug tracker:

https://bugs.gentoo.org/show_bug.cgi?id=425668

This behavior is triggered by the following commit to GNU Grep and reverting it has been shown to prevent the problem:

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=582cdfacf297181c2c5ffec83fd8a3c0f6562fc6

It does not occur on any other Linux filesystem. This might be related to bug #764, although I have no evidence for that. The only similiarity is that the ZFS Posix Layer is doing something strange.

Contributor

dechamps commented Aug 2, 2012

I don't see how this is a bug in ZFS. stat(2) on my system has the following declaration:

 blkcnt_t  st_blocks;  /* number of 512B blocks allocated */

Here is a comment taken from the grep commit:

If the file has fewer blocks than would be needed to represent its data, then it must have at least one hole.

That's just wrong. If the file is compressed by the file system, then it can be allocated using fewer blocks, but that doesn't mean it's a sparse file. The author of the grep commit is using st_blocks, which is meant as an informational hint, as element of proof to conclude that the file is sparse. That's a very, very audacious interpretation of the semantics of st_blocks.

Has this been discussed with the grep authors or should someone drop a mail in their mailing list so, hopefully, they will realize that with complex filesystems like ZFS and btrfs, the number of blocks allocated for a file has little to do with its actual contents? Why should we make ZFS lie about the number of blocks it allocates for a file (which is useful information for the administrator: that's what makes du reliable) just because someone happened to misuse the field in one popular program?

You can break grep or du. Pick your poison.

Owner

behlendorf commented Aug 3, 2012

Indeed this is an issue with grep.

I don't believe anyone has brought this to their attention yet. We should since they're going to have to make the fix.

Member

ryao commented Aug 3, 2012

I believe that they are already aware:

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=2f0255e9f4cc5cc8bd619d1f217902eb29b30bc2

I have asked people who are affected to test the upstream patch, but so far, no one has replied.

Also, I have received reports that this issue has been reproduced on btrfs (under certain kernel versions) and NFS.

behlendorf referenced this issue in zfsonlinux/spl Aug 7, 2012

Closed

Fedora 17: cannot compile anymore #141

Member

nedbass commented Aug 21, 2012

I noticed grep 2.14 was released yesterday with a fix for this bug.

Owner

behlendorf commented Aug 21, 2012

Yay. OK, we'll chalk this one up to documentation that grep 2.13 should be avoided and simply advise people to update as it appears in their distributions.

behlendorf closed this Aug 21, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment