From owner-freebsd-hackers Wed Feb 16 18:49:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from builder.freebsd.org (builder.FreeBSD.ORG [204.216.27.24]) by hub.freebsd.org (Postfix) with ESMTP id 18A0137B5E4 for ; Wed, 16 Feb 2000 18:49:17 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by builder.freebsd.org (Postfix) with ESMTP id 068DD132E7 for ; Wed, 16 Feb 2000 18:48:36 -0800 (PST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA21763; Thu, 17 Feb 2000 13:18:40 +1030 (CST) Date: Thu, 17 Feb 2000 13:18:39 +1030 From: Greg Lehey To: Matthew Dillon Cc: Joe Greco , Kenny Drobnack , hackers@FreeBSD.ORG Subject: Re: Filesystem size limit? Message-ID: <20000217131839.H20710@freebie.lemis.com> References: <200002152107.PAA75509@aurora.sol.net> <200002160012.QAA46218@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200002160012.QAA46218@apollo.backplane.com> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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