From owner-freebsd-doc@FreeBSD.ORG Sun Nov 24 06:12:26 2013 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BF967B9 for ; Sun, 24 Nov 2013 06:12:26 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7A7F206E for ; Sun, 24 Nov 2013 06:12:25 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rAO6CI83039133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 23 Nov 2013 22:12:18 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rAO6CIQx039132 for freebsd-doc@FreeBSD.org; Sat, 23 Nov 2013 22:12:18 -0800 (PST) (envelope-from jmg) Date: Sat, 23 Nov 2013 22:12:18 -0800 From: John-Mark Gurney To: freebsd-doc@FreeBSD.org Subject: What are the limits for FFS file systems? 10+ years out of date.. Message-ID: <20131124061218.GQ7069@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gE7i1rD7pdK0Ng3j" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 23 Nov 2013 22:12:18 -0800 (PST) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 06:12:26 -0000 --gE7i1rD7pdK0Ng3j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is a patch that bring this up to date.. This was written back when we were using UFS1 w/ 32bit block addresses... Things have changes now that UFS2 is standard... The big thing is listing the memory requirements for fsck as the main limiting factor on FS size... I've had Kirk review the patch, and he's fine w/ it... Shall I just commit it? Thanks for the review. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --gE7i1rD7pdK0Ng3j Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ffs.faq.patch" Index: book.xml =================================================================== --- book.xml (revision 43223) +++ book.xml (working copy) @@ -1338,92 +1338,25 @@ - For FFS file systems, the maximum theoretical limit is - 8 TB (2 G blocks), or 16 TB for the default - block size of 8 KB. In practice, there is a soft limit - of 1 TB, but with modifications file systems with - 4 TB are possible (and exist). + For FFS file systems, the largest file system is practically + limited by the amount of memory required to fsck the file + system. fsck requires one bit per fragment, which with the + the default fragment size of 4&nbps;KB equates to 32&nbps;MB + of memory per TB of disk. This does mean that on systems + which limit userland processes to 2&nbps;GB (such as i&nbps;386), + the maximum fsck'able filesystem is ~60&nbps;TB. + If there was not a fsck memory limit, the maximum + filesystem size is 2&nbps;^&nbps;64 (blocks) * 32&nbps;KB => + 16 Exa * 32&nbps;KB => 512 ZettaBytes. + The maximum size of a single FFS file is approximately - 1 G blocks, or 4 TB with a block size of - 4 KB. - - - Maximum File Sizes - - - - - FS Block Size - - Works - - Should Work - - - - - - 4 KB - - > 4 GB - - 4 TB - 1 - - - - 8 KB - - > 32 GB - - 32 TB - 1 - - - - 16 KB - - > 128 GB - - 32 TB - 1 - - - - 32 KB - - > 512 GB - - 64 TB - 1 - - - - 64 KB - - > 2048 GB - - 128 TB - 1 - - - -
- - When the FS block size is 4 KB, triple indirect - blocks work and everything should be limited by the maximum FS - block number that can be represented using triple indirect - blocks (approx. - 10243 + 10242 + 1024), - but everything is limited by a (wrong) limit of - 1 G - 1 on FS block numbers. The limit on FS - block numbers should be 2 G - 1. There are - some bugs for FS block numbers near 2 G - 1, - but such block numbers are unreachable when the FS block - size is 4 KB. - - For block sizes of 8 KB and larger, everything - should be limited by the 2 G - 1 limit on FS - block numbers, but is actually limited by the - 1 G - 1 limit on FS block numbers. Using the - correct limit of 2 G - 1 blocks does cause - problems. + 2 PB with the default block size of 32 KB. Each + 32 KB block can point to 4096 blocks. With triple + indirect blocks, the calculation is 32&nbps;KB * 12 + + 32&nbps;KB * 4096 + 32&nbps;KB * 4096^2 + 32&nbps;KB * + 4096^3. Increasing the block size to 64 KB will increase + the max file size by a factor of 16. --gE7i1rD7pdK0Ng3j--