[Gluster-users] Slow read performance

[Shawn Nock]

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>