[Gluster-devel] Local vs unify
Paul Arch
paul at esidium.com.au
Mon Apr 28 10:06:06 UTC 2008
<snip>
>> 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.
<snip>
I have been following this thread and the metadata stuff does interest me -
we have millions and millions of small files.
In the above situation though, I would of thought knowing all of the inputs
into the system ( ie - gluster knows that state everything is in, as long as
no-one enters and changes things from outside of the mechanism in the
back-ground ) could see some fair potential for caching the meta data. If
the system is in a degraded state sure you wouldn't and shouldn't trust this
cache, but all things being equal and happy, why can't we trust a good sized
cache metadata is AFR/unity/whatever is reporting the system is happy and
operational ?
Cheers
Paul
More information about the Gluster-devel
mailing list