begin  quote
On Wed, 13 Oct 2004 00:31:34 -0700
"Robin H. Johnson" <robbat2@g.o> wrote:

> The one thing that your (previously known) method does bring out is
> that reducing the I/O required really helps.

Agreed,  preferrably we should be able to distribute a bin-ball of the
files that we can rsync out, since if a file doesn't move inside it (as
is the case with filesystems) they stay on the same place and gets good
replication in rsync.


> Pack it into a loopback reiserfs instead, way better performance. 
actually not.  it kills performance to put a journalled filesystem
in a loopback system onto a data-journalling filesystem.

I care more about data and fragmentation than I care about performance,
that was the sole reason I first spiralled it off like this. The tree is
constrained.

As for the reiser protectionist idea,   *cough*     I don't have good
experiences with reiser, tailpacking, and performance.


>  For an even bigger boost, put the loop file into tmpfs or use some
>  other direct memory scheme.

Kills reliability. And performance isn't everything.  (could just as
well increase write times on the hosting fs, increase it even more on
the loopback, then simply "cat filesystem.img > /dev/null"  before
operations.  I don't. )


Overall, I'm not after complete performance.  I walk the middle road,
between performance and reliability.   


//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end