On Fri, Dec 19, 2003 at 09:41:35PM +0100, Lionix wrote:
> But I feel a little bit desperate as I had developed something not so 
> far from it a couple weeks ago to test the future content of my coda 
> server set, and be sure it would be possible acording to coda limits, 
> identify breacking points to them, and estimate the ammount of RVM I 
> would have to set up .... The result was quit interesting as I discover 
> I need less than 100MB of RVM to store more than 35GB of data !

I was pleasantly surprised at how often the 4% rule is overestimating as
well. The only thing is that the exact counting ignores things like
fragmentation, and the RVM allocator uses a simple first-fit allocator.
So in reality we might actually use significantly more RVM data than
really necessary.

Michael changed the RVM allocation strategy to use a best-fit allocator.
This slows down allocations but reduces overall fragmentation by quite
a bit.

> I didn't introduce it as there is still some bugs ( full path 
> construction not well all the times: one charactere shifted, fuc.. 
> spaces troubles....  and top level informations are wrong ) and I don't 
> like other people to read/test my code until it is finished and well 
> debug. Moreover I have to adapt it for coda now, as I think a ls -lR on 
> the rootvolume would perhaps be a hard job for venus, and not so 
> intelligent at all.... It would be better idea to get volume mount 
> points and make such a work for each volumes !

Interesting. And better yet, more good ideas...

BTW, there is a perl-script called 'volmunge' (client-side /usr/sbin?)
which can walks a single volume. It uses cfs to figure out where we
cross into another volume.

> The dev ml is very poor at all.... Is it time to give the dev ml a new 
> health ?

Yeah, there isn't much development related discussion, except for the
couple on codalist ;)

Jan