Ed - I'll follow up on your request with engineering and professional services, can we get back to you Wednesday latest?
Thanks, Craig -- Craig Carl Sales Engineer; Gluster, Inc. Cell - ( 408) 829-9953 (California, USA) Office - ( 408) 770-1884 Gtalk - [email protected] Twitter - @gluster Installing Gluster Storage Platform, the movie! http://rackerhacker.com/2010/08/11/one-month-with-glusterfs-in-production/ From: "Ed W" <[email protected]> To: [email protected] 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 servers? 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? Thanks Ed W _______________________________________________ Gluster-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/gluster-devel
