jw schultz wrote:
>On Mon, Aug 05, 2002 at 05:42:18PM +0400, Hans Reiser wrote:
>
>
>>You might also mention that I think the limits imposed by Linux are the
>>only meaningful ones, as we would change our limits as soon as Linux
>>did, and it was Linux that selected our limits for us. We would have
>>changed already if Linux didn't make it pointless to change it on Intel.
>>Reiser4 will have 64 bit blocknumbers that will be semi-pointless until
>>64 bit CPUs are widely deployed, and I am simply guessing this will be
>>not very far into reiser4's lifecycle. Really, the couple of #defines
>>that constitute these size limits, plus some surrounding code, are not
>>such a big thing to change (except that it constitutes a disk format
>>change).
>>
>>
>
>Hans,
>
>My recollection is that reiser4 isn't released yet. Why not
>set the reiser4 disk format with 64 bit blocknumbers from
>dot? 32 bit archs could write zeros and otherwise ignore
>the upper 32 bits and refuse to mount if filesystem size
>would cause overflow. That way you avoid on-disk format
>change mid cycle. That seems a lot less overhead than
>coping with different datatypes.
>
>Of course if you'd rather support another on-disk format
>to squeeze a bit more data onto small drives i can understand.
>
>
>
We are using 64 bit blocknumbers in reiser4, and letting linux limit
them. Perhaps my writing style was rather lacking in clarity.....
Linux is going to use some hacks in 2.5 that will let it go moderately
above the 2.4 limits. 64 bit blocknumbers seem the most flexible thing
in the face of what will be ever evolving hacks followed by the
introduction of 64 bit CPUs into the mainstream.
-- Hans- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:30 EST