Re: [Gluster-users] Slow read performance

Sorry for the late reply. The call profiles look OK on the server side. I suspect it is still something to do with the client or network. Have you mounted the FUSE client with any special options? like --direct-io-mode? That can have a significant impact on read performance as read-ahead in the pag

Re: [Gluster-users] Slow read performance

Joe, Understood. No problem at all. Regards, Rodrigo On Mon, Mar 11, 2013 at 7:24 PM, Joe Julian wrote: > I apologize. I normally tend to try to be much more eloquent with my > debates. > > I woke up this morning to learn that the CentOS 6.4 rollout broke all my > end-user stations (yes,

Re: [Gluster-users] Slow read performance

I apologize. I normally tend to try to be much more eloquent with my debates. I woke up this morning to learn that the CentOS 6.4 rollout broke all my end-user stations (yes, I have to do automatic updates. I just don't have time to review every package and do everything else I need to do all

Re: [Gluster-users] Slow read performance

- Original Message - > On Mon, Mar 11, 2013 at 4:04 PM, Joe Julian < j...@julianfamily.org > > wrote: > > Which is why we don't run Rodigux > > Oh Joe, that remark sounds rather inappropriate to me.\ Agreed - rule #1 on gluster.org is 'be respectful'. You made a valid point. -JM ___

Re: [Gluster-users] Slow read performance

On Mon, Mar 11, 2013 at 4:04 PM, Joe Julian wrote: > Which is why we don't run Rodigux > Oh Joe, that remark sounds rather inappropriate to me. Apparently we disagree on more levels that just kernel and applications compatibility policies. Regards, Rodrigo Severo > > > On 03/11/2013 12:02

Re: [Gluster-users] Slow read performance

Which is why we don't run Rodigux On 03/11/2013 12:02 PM, Rodrigo Severo wrote: On Mon, Mar 11, 2013 at 3:46 PM, Bryan Whitehead > wrote: This is clearly something Linus should support (forcing ext4 fix). There is an ethos Linus always champions and that is

Re: [Gluster-users] Slow read performance

On Mon, Mar 11, 2013 at 3:46 PM, Bryan Whitehead wrote: > This is clearly something Linus should support (forcing ext4 fix). There > is an ethos Linus always champions and that is *never* break userspace. > NEVER. Clearly this ext4 change has broken userspace. GlusterFS is not in > the kernel at a

Re: [Gluster-users] Slow read performance

This is clearly something Linus should support (forcing ext4 fix). There is an ethos Linus always champions and that is *never* break userspace. NEVER. Clearly this ext4 change has broken userspace. GlusterFS is not in the kernel at all and this change has broken it. On Mon, Mar 11, 2013 at 11:34

Re: [Gluster-users] Slow read performance

If you prefer to say that Linus recent statement isn't pertinent to Gluster x ext4 issue (as I do), or that ext4 developers are being hypocritical/ignoring Linus orientation (as you do) or anything similar isn't really relevant any more. This argument could have been important in March 2012, the m

Re: [Gluster-users] Slow read performance

As I read this: > https://bugzilla.redhat.com/show_bug.cgi?id=838784 the bug is, from Gluster's POV, between ext4 and the kernel. Is this correct, that Gluster can't safely use ext4 on recent kernels until ext4's relationship with the kernel is fixed? If Gluster can't be simply patche

Re: [Gluster-users] Slow read performance

- Original Message - > I know where this statement came from. I believe you are both: > * trying to apply some statement on a context it's not pertinent to > and No, it's actually quite applicable. I'm aware of the context of that statement by Linus, and it applies to this case. Kernel

Re: [Gluster-users] Slow read performance

Joe Julian 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.g

Re: [Gluster-users] Slow read performance

I know where this statement came from. I believe you are both: - trying to apply some statement on a context it's not pertinent to and - fouling yourself and/or others arguing that this issue will/should be fixed in the kernel. The ext4 hash size change was applied in the kernel an year

Re: [Gluster-users] Slow read performance

On 03/11/2013 12:02 PM, Thomas Wakefield wrote: > Is there a way to make a ramdisk support extended attributes? When I need a ramdisk, I usually do it this way: * Use "dd if=/dev/zero ..." to create a large file in tmpfs, which can use swap but will behave like a ramdisk as long as there's memory

Re: [Gluster-users] Slow read performance

I really do wonder if this bug in _glusterfs_ is not fixed. It really makes no sense to do an implementation that breaks on the most used fs on linux. And just as you said: don't wait on btrfs, it will never be production-ready. And xfs is no solution, it is just a bad work-around. On Fri, 8 Mar

Re: [Gluster-users] Slow read performance

Have you run oprofile on the client and server simultaneously to see if there's some race condition developing? Obviously the NFS client is fine, but it's clear that there's nothing wrong with the hardware. oprofile will at least reveal where the the bits are vacationing and may point a specif

Re: [Gluster-users] Slow read performance

Every time you open/close a file or a directory you will have to wait for locks which take time. This is totally expected. Why don't you share what you want to do? iozone benchmarks look like crap but serving qcow2 files to qemu works fantastic for me. What are you doing? Make a benchmark that doe

Re: [Gluster-users] Slow read performance

How are you doing the read/write tests on the fuse/glusterfs mountpoint? Many small files will be slow because all the time is spent coordinating locks. On Wed, Feb 27, 2013 at 9:31 AM, Thomas Wakefield wrote: > Help please- > > > I am running 3.3.1 on Centos using a 10GB network. I get reasona