Hi Alain, Gareth, Replies inline. On Sun, Apr 27, 2008 at 5:33 AM, Gareth Bult <gareth@xxxxxxxxxxxxx> wrote: > >Are there some benchmrks available about this ? > > I'm not entirely sure how useful benchmarks are, certainly in this > context. As demonstrated by the benchmarks currently on the site, it's quite > possible to make them show pretty much whatever you want if you pick your > own context. > > Gluster REALLY is quick in some contexts, certainly I can make Gluster > look quick compared to NFS if we're talking about access to a single file or > copying larger files. If on the other hand we're talking smaller files (i.e. > many real world situations) then Gluster falls flat. "find" on a large > gluster FS can take minutes rather than seconds on a local FS (for example). > As we are talking about Distributed/Clustered FS, we haven't given any benchmark comparing to NFS or localdisk. > > It may of course be I'm doing it all wrong .. however (!) if I am, given > the time I've spent and the fact that I do have it all working, there may be > room for improvement when it comes to the documentation (!) Yes! agreed. When ever we tried to improve upon documentation, we don't see problem as we can't see it as a newbie, we end up writing a proper spec file, compiling properly, etc, hence we requested all to point out to errors in Documentation so we can correct it. Till now we have corrected all those pages/errors which were pointed out here through mailing-list. > > >local storeage CAN be notable > > Note; gluster (in particular AFR) on large files is currently flawed > (IMHO). gluster on lots of small files is, as far as I can see flawed in the > context of being too slow compared to local file-system access. This is not > to say that Gluster is not useful or that issues cannot be fixed. > Again, we are not comparing with local disk. But still our goal is to reach near disk speed with using Infiniband RDMA. Already we have reached it for I/O performance. As we have no metadata server, (namespace is just a cache, not metadata), the clustered performance for metadata will surely look poor compared to localdisk, we are working on enhancing our metadata performance too. > > You might be advised to setup your own test framework and test with your > own data to get a true measure of how Gluster will perform for "you" in > "your" environment ... Gluster is SO flexible, generic benchmarks can often > be nothing more than speculation.. > Just to clarify; I think Gluster's general design is second to none .. I > just there there are still a few implementation glitches to work through ... > Thanks for supporting our design. We are working towards fixing those few glitches! But true that things are not changing as fast as we have wished. Each new idea needs time to get converted into code, get tested. Hence bit delay in things. > Gareth. > > > ----- Original Message ----- > From: "Alain Baeckeroot" <alain.baeckeroot@xxxxxxxxxxx> > To: gluster-devel@xxxxxxxxxx > Sent: Sunday, April 27, 2008 8:04:55 AM GMT +00:00 GMT Britain, Ireland, > Portugal > Subject: Re: [Gluster-devel] Local vs unify > > Le samedi 26 avril 2008, Gareth Bult a écrit : > > Technically, if you have local storage on each node then GlusterFS/Unify > is a useful solution, but the performance overhead compared to local > storeage can be notable. > > > > Are there some benchmrks available about this ? > > Regards > Alain Baeckeroot > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel > -- Amar Tumballi Gluster/GlusterFS Hacker [bulde on #gluster/irc.gnu.org] http://www.zresearch.com - Commoditizing Super Storage!
