arla-block-TR1 compilation problem

[Tomas Olsson]

Anders Selander <selander at pdc.kth.se> writes:
> On Thu, Nov 16, 2006 at 02:54:39PM +0100, Tomas Olsson wrote:
> > Did you look at http://jdurand.home.cern.ch/jdurand/arla/ ? 
> 
> Nope - I had no idea that there are debs for fresher versions of arla.
> In the central Ubuntu/Debian repository, there are still only 0.36 
> ones.
>
It really would be nice if one could make them (or similar) official.

> > > think that arla-on-blocks will have something to offer when one saves an
> > > email in an already very huge folder stored in afs. ;-)
> > Hmm, I'm not so sure about that one. Most of the fixes for that are still
> > on the TODO list. But maybe you'll see some improvement anyway.
> 
> Eh? I thought that was the general idea of block caching, to only have
> to cache parts of the file and not all of it? Can you please elaborate
> a little? 
>
Well, it depends on what/where the bottleneck is and what you mean with
'folder'.

For directories:
 We still always fetch the entire dir, though perhaps slightly less often.
 Lookups are still O(n) in directory size (not counting OS's name cache).

For files:
 We still write the entire file when possible, I'm still paranoid about
 consistency.
 We still do write on close.

All of these things may of course be changed (at some cost), but so far
we've focused on getting it stable and been happy enough with the main
points -- to be able to read and write files larger than your cache, and
only needing to fetch the part you actually want when reading a file.

So when it comes to write performance, I don't think we currently have any
major improvements, but for some partial reads the difference is huge.

> Hmm, I'll think I'll wait around for another release rather than
> starting to remove references on my own. ;-)
> 
Ok, cvs HEAD does work fairly well (I have real users :)), but I hope to be
able to release a TR2 within a few weeks.

/t