Date: Sun, 25 Feb 2001 15:34:18 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: David Gilbert <dgilbert@velocet.ca> Cc: Bernd Walter <ticso@cicely5.cicely.de>, freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Large MFS on NFS-swap? Message-ID: <200102252334.f1PNYIf18842@earth.backplane.com> References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> <200102250644.f1P6iuL12016@earth.backplane.com> <15001.21129.307283.198917@trooper.velocet.net> <200102251913.f1PJDAc15495@earth.backplane.com> <15001.35517.468307.915125@trooper.velocet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:Making the run for larger block sizes puts us in the same league as
:DOS. While it will stave off the wolves, it will only work for so
:long give Moore's law.
:
:Dave.
:
:--
:============================================================================
:|David Gilbert, Velocet Communications. | Two things can only be |
Ultimately the limit we face is the fact that we use 32 bit quantities
to store block numbers. At 512 bytes per block, and assuming only 31
bits of useful space, we are limited to 2G x 512 = 1TB. (filesystems
such as FFS use 'negative' block numbers for special purposes).
Within the kernel we have already moved to 64 bit offsets for everything
that is offset-based. Block numbers however are still 32 bits. There
have been a number of proposals on how to solve the problem and the one
that will probably win in the end will be to pass 64 bit offsets all the
way through to the low level disk I/O. e.g. we would still guarentee
appropriate block boundries for the offsets when passing them through
to the device level, but we would not do the divide that we currently
do.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102252334.f1PNYIf18842>