[Gluster-devel] Local vs unify

gordan at bobich.net gordan at bobich.net
Mon Apr 28 09:56:18 UTC 2008


On Mon, 28 Apr 2008, Gareth Bult wrote:

> b. Having people on the mailing list say "yeah, but it was designed this 
> way", implying no changes were expected to the way it works, isn't all 
> that helpful .. if nobody is going to pipe up and say "we working on 
> it".

I think the point to consider here (and I speak as a GlusterFS user, not a 
developer/contributor - just thought I'd stress that point) is that the 
major plus point of GlusterFS is that it gives POSIX locking that make the 
FS behave in a sane way when used in a cluster. If you don't need this, 
then you might as well use something like Coda which is _much_ more 
loosely coupled.

I'd personally much rather have two tools for two fundamentally different 
jobs (tightly coupled LAN Cluster FS (GlusterFS) vs. loosely coupled WAN 
replicated/global FS (Coda)) instead of one tool that tries to do both and 
ends up not being as good at either.

>> 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.
>
> No problem and thank you for this email, it has answered a major issue 
> for me .. I am of course going to ask;
> a. Any timescale on the metadata changes?
> b. How much of a difference will it make.. will we be approaching 
> local(ish) speeds .. or are we just talking x2 of current?

I imagine that would depend on the metadata expiry timeouts. If it's set 
to 100ms, the chances are that you won't see much improvement. If it's set 
for 100 seconds, it'll go as fast as local FS for cached data but you'll 
be working on FS state that might as well be imaginary in some cases. No 
doubt someone will then complain about the fact that posix semantics no 
longer work.

Gordan





More information about the Gluster-devel mailing list