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
