<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
