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. avati 2007/8/8, Nathan Allen Stratton <nathan@xxxxxxxxxxxx>: > > On Wed, 8 Aug 2007, Harris Landgarten wrote: > > > I just ran some speed tests with tla 441 and fuse-2.7.0-gls3 > > I am running tla 439, but haveing the same issues with write-behind and > read-ahead. We are only talking about 134M.... > > TLA-439 > write-behind on > read-ahead on > > [root@vs0 share]# time cp /usr/bin/* /share/test/ > real 2m24.436s > [root@vs0 share]# time cp -r /share/test/ /share/test2 > real 3m14.409s > [root@vs0 share]# time rm -fr test* > real 0m47.418s > > TLA-439 > write-behind off > read-ahead on > > [root@vs0 /]# time cp /usr/bin/* /share/test/ > real 1m51.529s > [root@vs0 /]# time cp -r /share/test/ /share/test2 > real 2m52.947s > [root@vs0 /]# time rm -fr test* > real 0m59.132s > > TLA-439 > write-behind off > read-ahead off > > [root@vs0 share]# time cp /usr/bin/* /share/test/ > real 1m45.248s > [root@vs0 share]# time cp -r /share/test/ /share/test2 > real 2m28.788s > [root@vs0 share]# time rm -fr /share/test* > real 1m1.128s > > > > ><> > Nathan Stratton CTO, Voila IP Communications > nathan at robotics.net nathan at voilaip.com > http://www.robotics.net http://www.voilaip.com > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel > -- It always takes longer than you expect, even when you take into account Hofstadter's Law. -- Hofstadter's Law
