RE: [Gluster-devel] Local vs unify

[Paul Arch]

<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