From owner-freebsd-hackers  Tue Feb 15  9:56:11 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by builder.freebsd.org (Postfix) with ESMTP id 4C4564C34
	for <hackers@FreeBSD.ORG>; Tue, 15 Feb 2000 09:51:13 -0800 (PST)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA44270;
	Tue, 15 Feb 2000 09:50:13 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 15 Feb 2000 09:50:13 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200002151750.JAA44270@apollo.backplane.com>
To: Joe Greco <jgreco@ns.sol.net>
Cc: peter@netplex.com.au (Peter Wemm), hackers@FreeBSD.ORG
Subject: Re: Filesystem size limit?
References:  <200002151608.KAA54469@aurora.sol.net>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:> ie: there is a signed 32 bit sector count limit.  2^31 == 1TB.  It shouldn't
:> be too hard to get it to create 2^32 bit (2TB) filesystem though.  I'd expect
:> there to be more problems that this to bite you though. :-(
:> 
:> 2^31 also happens to be the mmap() file offset limit FWIW.

    2^31 blocks is the limit, because the filesystem uses negative block 
    numbers internally to represent metadata.

    Theoretically you can use a larger block size and a larger sector size
    and thus get more blocks, but unfortunately the kernel's device interface
    translates everything to 512-byte blocks.  It is not an insurmountable 
    problem, though, I can definitely see us supporting 2^31 x large_block 
    filesystems in the future.  E.G. where a 64K block size would yield 
    a 128TB max fs size.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message