Re: Stability of ReiserFS onj Kernel 2.4.x (sp. 2.4.[56]{-ac*}

Daniel Phillips
2001-07-16T22:26:40Z

On Monday 16 July 2001 21:16, Hans Reiser wrote:
> Jussi Laako wrote:
> > Daniel Phillips wrote:
> > > We are not that far away from being able to handle 8K blocks, so
> > > that would bump it up to 32 TB.
> >
> > That's way too small. Something like 32 PB would be better... ;)
> > We need at least one extra bit in volume/file size every year.
>
> Daniel, if I was real sure that 64k blocks were the right answer, I
> would agree with you. I think nobody knows what will happen with
> reiserfs if we go to 64k blocks.

For 32 bit block numbers:

Logical Block Size Largest Volume
------------------ --------------

4K 16 TB
8K 32 TB
16K 64 TB
32K 128 TB
64K 256 TB

You don't have to go to the extreme of 64K blocksize to get big
volumes. Anyway, with tailmerging there isn't really a downside to big
blocks, assuming the tailmerging code is fairly mature and efficient.
Maybe that's where we're still guessing?

> It could be great. On the other
> hand, the average number of bytes memcopied with every small file
> insertion increases with node size. Scalable integers (Xanadu
> project idea in which the last bit of an integer indicates whether
> the integer is longer than the base size by an amount equal to the
> base size, chain can be infinitely long, they used a base size of 1
> byte, but we could use a base size of 32 bits, and limit it to 64
> bits rather than allowing infinite scaling) seem like more
> conservative coding.

Yes, I've used similar things in the past, but only in serialized
structures. In a fixed sized field it doesn't make a lot of sense.

--
Daniel