[Gluster-devel] speed tests with gls3 fuse and tla 441

[Nathan Allen Stratton]

On Thu, 9 Aug 2007, Anand Avati wrote:

> Harris/Nathan,
>  I am looking into the issue. the performance seems to be a problem for
> small files (which get passed on in one write() call to the filesystem). The
> actual delay seems to be coming from either VFS/fuse. When write-behind
> replies back 'written' that fast, there seems to be some kind of 'idling'
> before getting further calls from fuse. The write-behind definitely seems to
> make a positive difference for large files though. I am investigating this
> deeper currently.

[root at vs0 share]# ls -lh vs1_video2_17_2007-08-08.rs
-rw-r--r-- 1 root root 5.2G Aug  8 17:53 vs1_video2_17_2007-08-08.rs

With write and read off:

[root at vs0 share]# time cp vs1_video2_17_2007-08-08.rs foo.rs

real    5m10.283s
user    0m0.035s
sys     0m9.059s

With write and read on:

[root at vs0 share]# time cp vs1_video2_17_2007-08-08.rs foo.rs


real    28m34.235s
user    0m0.008s
sys     0m1.458s


My setup is:

vs0     /md0 brick-a    /md1 mirror-c   /ns ns-a-brick
vs1     /md0 brick-b    /md1 mirror-a   /ns ns-b-brick
vs2     /md0 brick-c    /md1 mirror-b   /ns ns-c-brick

block-ns-afr    *:3     brick-a-ns brick-b-ns brick-c-ns
block-a-afr     *:2     brick-a mirror-a
block-b-afr     *:2     brick-b mirror-b
block-c-afr     *:2     brick-c mirror-c
share-unify     block-a-afr block-b-afr block-c-afr

All boxes are on dedicated gig e for gluster. This file is in vs0:/md0 so
the same box the client it hitting, I would think I would see much better
IO then 16 meg a sec.