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.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.wsRemember Cernan and Schmitt - 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:29 EST