Joe Julian <joe at julianfamily.org> writes: > This bug is in the kernel. > > "If a change results in user programs breaking, it's a bug in the > kernel. We never EVER blame the user programs." - Linus Torvalds > > http://lkml.org/lkml/2012/12/23/75 Understood. However, there was an update to your post here: http://www.gluster.org/2012/08/glusterfs-bit-by-ext4-structure-change/ : "It [a patchset for gluster addressing the ext4 changes] is still being actively worked on, though, and is a high priority." The 'high priority' bit raised a few expectations; that was more than 6 months ago. While I feel like the gluster devs don't owe me anything, this issue does effect pretty much every user with an ext3/4 brick. There (to my recollection) hasn't been any guidance on how the community should address this in their installations. It's pretty clear in the Redhat Storage docs that Gluster has XFS (and lvm) as a hard dependency... but the 3.3 admin guide dosn't say anything useful (about fs choice) and it 3.1/3.2 docs used to recommend ext4 as a well tested option. It doesn't seem like there's any talk of reverting the commit in the mainline kernel. It seems to be very useful for preventing hash collisions for a lot of kNFS+ext3/4 workflows and it's been backported to the enterprise distributions. It's not a gluster bug, but it's here to stay. What do we do now? (Rhetorical question, I am removing bricks and reformatting with xfs and the re-adding/rebalancing... slowly). -- Shawn Nock (OpenPGP: 0x65118FA5) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130311/fb06d037/attachment.sig>
