>lookup() will always have to be done on all the subvols >So the delay can not be avoided. Urm, each volume should be a complete copy .. so why would it need to reference all subvolumes? It's not like it's trying to lock a file or anything ... ?? One very valid use case for Gluster is for replication for read-mostly volumes over slow links. This limitation makes gluster unusable over slow links, which seems like a fairly critical limitation. (indeed both AFR and Unify are unusable over ADSL .. this is probably something worth mentioning a little more clearly in the documentation, I've run into a number of people who've wasted quite a bit of time thining they were at fault ..) In addition, I was previously trying to use a gluster filesystem as a platform to share a "Products" folder for a zope instance. I couldn't understand why zope was taking 7 minutes to start rather than 20 seconds .. further investigation revealed it was purely down to filesystem information access re; loading lots of small scripts. This was on an AFR volume over a 1Gb network link .. THAT is how much difference it makes, 20 seconds -> 7 minutes .. surely this level of impact on filesystem performance deserves a little more priority ? Overall I think the modular design of gluster is fantastic and it fills a critical need for users .. it's just a real shame that it comes up short in a few key areas. :-( Gareth. ----- Original Message ----- From: "Krishna Srinivas" <krishna@xxxxxxxxxxxxx> To: "Gareth Bult" <gareth@xxxxxxxxxxxxx> Cc: "gluster-devel Glister Devel List" <gluster-devel@xxxxxxxxxx> Sent: Wednesday, April 23, 2008 3:47:57 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: Re; Load balancing ... If you are using find, then it does lookup() in addition to readdir, and lookup() will always have to be done on all the subvols. So the delay can not be avoided. We will check if we can do something about working things out from the "read-subvolume" option. Krishna On Wed, Apr 23, 2008 at 6:32 PM, Gareth Bult <gareth@xxxxxxxxxxxxx> wrote: > Urm, > > Yes I can .. although I meant "filesystem information" generically rather than "ls". > My "real" test is using "find" .. which is unaffected by "unalias ls" .. > > If your question is; > After "unalias ls" does the client still read filesystem information from BOTH servers"? > > The answer is; > Yes .. according to tcpdump. > > Gareth. > > > -- > Managing Director, Encryptec Limited > Tel: 0845 5082719, Mob: 0785 3305393 > Email: gareth@xxxxxxxxxxxxx > Statements made are at all times subject to Encryptec's Terms and Conditions of Business, which are available upon request. > > > > ----- Original Message ----- > From: "Krishna Srinivas" <krishna@xxxxxxxxxxxxx> > To: "Gareth Bult" <gareth@xxxxxxxxxxxxx> > Cc: "gluster-devel Glister Devel List" <gluster-devel@xxxxxxxxxx> > Sent: Wednesday, April 23, 2008 12:56:27 PM GMT +00:00 GMT Britain, Ireland, Portugal > Subject: Re: Re; Load balancing ... > > Gordon, > > can you do "unalias ls" and see if ls is still slow? > > Krishna > > On Wed, Apr 23, 2008 at 3:14 PM, Gareth Bult <gareth@xxxxxxxxxxxxx> wrote: > > Hi, I'm using fuse-2.7.2glfs9 and glusterfs-1.3.8pre5 .. > > > > Using AFR and "option read-subvolume" I'm expecting to be able to tell a client which server to prefer to read data from. Although this seems to work for pure data, it does not appear to work for file-system information .. so "dd" on a large file is quick and "ls" is very slow. > > > > Can anyone tell me if "read-subvolume" should affect filesystem data and whether there is a way of speeding up what I'm doing. > > i.e. can I tell it which volume to prefer for filesystem information lookups? > > > > (effectively this is a read-mostly server running over a slow link .. basicall reads are good, "ls"'s are impossibly slow) > > > > tia > > > > --- Server --- > > > > volume brick-raw > > type storage/posix > > option directory /vols/home/export > > end-volume > > > > volume brick > > type features/posix-locks > > subvolumes brick-raw > > option mandatory on > > end-volume > > > > volume server > > type protocol/server > > option transport-type tcp/server > > option auth.ip.brick.allow <ip's> > > subvolumes brick > > end-volume > > > > --- Client --- > > volume brick1 > > type protocol/client > > option transport-type tcp/client > > option remote-host brick1 > > option remote-subvolume brick > > end-volume > > > > volume brick2 > > type protocol/client > > option transport-type tcp/client > > option remote-host brick2 > > option remote-subvolume brick > > end-volume > > > > volume afr > > type cluster/afr > > subvolumes brick1 brick2 > > option read-subvolume brick1 > > end-volume > > > > volume writebehind > > type performance/write-behind > > option aggregate-size 131072 > > subvolumes afr > > end-volume > > > > volume readahead > > type performance/read-ahead > > option page-size 65536 > > option page-count 16 > > subvolumes writebehind > > end-volume > > > > -- > > Managing Director, Encryptec Limited > > Tel: 0845 5082719, Mob: 0785 3305393 > > Email: gareth@xxxxxxxxxxxxx > > Statements made are at all times subject to Encryptec's Terms and Conditions of Business, which are available upon request. > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel@xxxxxxxxxx > > http://lists.nongnu.org/mailman/listinfo/gluster-devel > > >
