Date: Thu, 17 Feb 2000 13:18:39 +1030 From: Greg Lehey <grog@lemis.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Joe Greco <jgreco@ns.sol.net>, Kenny Drobnack <kdrobnac@mission.mvnc.edu>, hackers@FreeBSD.ORG Subject: Re: Filesystem size limit? Message-ID: <20000217131839.H20710@freebie.lemis.com> In-Reply-To: <200002160012.QAA46218@apollo.backplane.com> References: <200002152107.PAA75509@aurora.sol.net> <200002160012.QAA46218@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 15 February 2000 at 16:12:36 -0800, Matthew Dillon wrote: >> sure your amount of metadata that needs checking is reasonably low. >> >>> Also, it seems like 64 bit processors will be in use before 1 TB >>> filesystems are common. Won't the filesystem need to be 64-bitted for >>> that? >> >> I would guess. Matt Dillon commented on this already, though, and is much >> better suited to having an opinion about it. > > Personally I think going to 64 bit block numbers is overkill. 32 bits > is plenty (for the next few decades) and, generally, people running > filesystems that large tend to be in the 'fewer larger files' category > rather then the 'billions of tiny files' category, so using a large > block size is reasonable. At the moment the filesystem block size is > the kernel's minimum disk I/O (at least when accessing portions backed > by full blocks), but it is far more likely that we change the kernel > to do less then full block reads then it is that we bump up the block > number to 64 bits. I think that at some point we'll need larger block numbers than will no longer fit in 32 bits. I'd rather we went to byte offsets, though, rather than block numbers. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20000217131839.H20710>