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@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@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@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.
