[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Can I bring a development idea to Dev's attention?

From: Craig Carl
Subject: Re: [Gluster-devel] Can I bring a development idea to Dev's attention?
Date: Sat, 25 Sep 2010 21:02:44 -0500 (CDT)

Ed -
    I'll follow up on your request with engineering and professional services, can we get back to you Wednesday latest?



Craig Carl
Sales Engineer; Gluster, Inc.
Cell - (408) 829-9953 (California, USA)
Office - (408) 770-1884
Gtalk - address@hidden
Twitter - @gluster
Installing Gluster Storage Platform, the movie!

From: "Ed W" <address@hidden>
To: address@hidden
Sent: Saturday, September 25, 2010 5:35:21 PM
Subject: Re: [Gluster-devel] Can I bring a development idea to Dev's attention?

  Does someone from Gluster like to contact me with a "reasonable" offer
for sponsoring some kind of "optimistic cache" feature, with a specific
view to optimising the NUFA server side replication architecture?

I would specifically like to optimise the case that you have a flat
namespace on the server (master/master filesharing), but you optimise
the applications in such a way that the applications running on each
brick (NUFA) only touch a subset of all files (in general).  eg a
mailserver with a flat filesystem, but users are proxied so that they
generally touch only a specific server, or a webserver with a flat
namespace where a proxy points specific domains to be served by specific

In this case I would like to see a specific brick realise that it's
predominantly the reader/write for a subset of all files and optimise
it's access at the expense of other bricks which need to access the same
files (ie I don't just want to turn up the writeback cache, I want cache
coherency across the entire cluster).  I would accept that random
read/writes to random bricks would be slower, in return for the
optimisation that reads/writes would be faster *if* the clients optimise
themselves to *prefer* to touch specific bricks (ie NUFA).  Such an
optimisation should not be set in stone of course, if the activity on a
subdirectory generally seems to move across to another brick then that
brick should eventually optimise it's read/write performance (at the
expense that another brick's access now becomes slower to that same
subset of files.)

Anyone care to quote on this?  Seems like it's a popular performance
issue on the mailing list and with some optimisation later it also seems
like the basis for cross datacenter replication?


Ed W

Gluster-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]