From owner-freebsd-current@FreeBSD.ORG Sat Jul 3 07:54:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DE1E16A4CE; Sat, 3 Jul 2004 07:54:51 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9541D43D48; Sat, 3 Jul 2004 07:54:50 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i637sm5v026887; Sat, 3 Jul 2004 17:54:48 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i637skao013968; Sat, 3 Jul 2004 17:54:47 +1000 Date: Sat, 3 Jul 2004 17:54:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Kenneth D. Merry" In-Reply-To: <20040702192335.GA42513@panzer.kdm.org> Message-ID: <20040703171141.T7639@gamplex.bde.org> References: <20040702163759.GA41401@panzer.kdm.org> <20040702192335.GA42513@panzer.kdm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: UFS2 filesystem and filesize limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2004 07:54:51 -0000 On Fri, 2 Jul 2004, Kenneth D. Merry wrote: > On Fri, Jul 02, 2004 at 10:37:59 -0600, Kenneth D. Merry wrote: > > > > I've searched a bit on the list archives, but didn't find an obvious answer > > so I thought I'd ask: > > > > What is the maximum possible size of a UFS2 filesystem? Are there any > > gotchas associated with going that large? > > > > What is the maximum possible file size on a UFS2 filesystem? It is given by the same formula as for any ffs file system. The main limit is that there are only 3 levels of triple indirection, so not many more than N**3 logical blocks can be addressed, where N = <(illogical) block size> / . The size of a logical block address is twice as large for ffs2, so N is twice as small and the limit on the maximum possible file size from triple indirection is about 2**3 = 8 times as small for ffs2 as for ffs1. There is a secondary limit that only affects ffs1. File sizes are restricted by the size of a logical block address. For ffs1 this limit is 2**31 * . For ffs2 it is 2**63 * . Since file sizes (or at least file offsets) are limited to 2**63-1 by off_t being 64 bits signed, the latter limit is irrelevant since other limits are much more restrictive. The N**3 limit is also much more restrictive for non-proposterous values of . The ffs1 limit is also reduced by an off-by-1 error in its 2**31 limit (limit is 2**30 * ) and a bug (overflow at 1TB). The default block sizes of 16K/2K combined with ffs2's 64-bit lba's give N = 2048 and N**3 * = 16TB. The actual limit is a little larger (add terms of N**2 + N + C -- these are dominated by the N**3 term). The corresponding limits for ffs1 are: - 128TB (N**3 term) - 4TB (2**31 term) - 2TB (2**30 term) - 1TB (overflow bug) > Evidently there are some limits. I can create a 11TB filesystem, but I can > only put 714GB or so on it: > > # dd if=/dev/zero of=bigfile bs=1m > > /bigdisk: write failed, filesystem is full > dd: bigfile: No space left on device > 730368+0 records in > 730367+0 records out > 765845307392 bytes transferred in 11211.369691 secs (68309701 bytes/sec) The error isn't EFBIG, so it is apparently unrelated to file siszes. Apparently there are bugs in the block allocator for such large file systems. Your other debugging output is consistent with this [writing of additional big files fails much sooner but not immediately]. Look for overflow near the freespace() calculations. Bruce