Re: Can I bring a development idea to Dev's attention?

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

 



Any news? Wed latest seems to have been and gone?

I think some kind of optimistic locking is the kind of thing which pushes Gluster into the high performance bracket (without needing 40GB cards, which when you think about it kind of ends up creating just one big NUMA machine rather than a cluster setup)

If the kernel NLM can do this satisfactorily then seems like things get even better?

Cheers

Ed W

On 26/09/2010 03:02, Craig Carl wrote:
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



From: "Ed W" <lists@xxxxxxxxxxxxxx>
To: gluster-devel@xxxxxxxxxx
Sent: Saturday, September 25, 2010 5:35:21 PM
Subject: Re: 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
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel


[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux