From owner-freebsd-fs@FreeBSD.ORG Mon Jan 14 02:38:01 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2EB294D for ; Mon, 14 Jan 2013 02:38:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 35618D41 for ; Mon, 14 Jan 2013 02:38:00 +0000 (UTC) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0E2bwBo026710 for ; Mon, 14 Jan 2013 13:37:58 +1100 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0E2bjxc027910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 13:37:48 +1100 Date: Mon, 14 Jan 2013 13:37:45 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Eitan Adler Subject: Re: What are the limits for FFS file systems and assorted questions In-Reply-To: Message-ID: <20130114120607.T1405@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zty1sKHG c=1 sm=1 a=kfiv9bC3p58A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=VR0RDpC6nxIA:10 a=uyavkMrdAAAA:8 a=6I5d2MoRAAAA:8 a=F9O_ex-_ffWYsS3ENVsA:9 a=CjuIK1q_8ugA:10 a=CA2XKIK3M3QA:10 a=JGX6LFFZUg8A:10 a=JXfXW3mLlncKNhj-:21 a=24pwTRVnVc0i8OkX:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 02:38:01 -0000 On Sun, 13 Jan 2013, Eitan Adler wrote: > Can anyone provide an up to date answer for the following: > > If these are all already perfect and correct can you please tell me so? > > On 18 December 2012 23:13, Eitan Adler wrote: > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ffs-limits >> Are the bugs listed still bugs? This almost useless, since it pre-dates ffs2. It seems to be derived from something I wrote in a mailing list. The "Should Work" column in the table is now implemented, but it is only for ffs1 and is buggy for a block sizes of 8K (the limit should be 16TB, not 32TB). The wording of the descriptions could be improved. All related known bugs for ffs1, including the ones described there, were fixed 5-15 years ago. But recent work on ext2fs showed a new one. A very minor one that only recently became reachable, but it has been fixed in Linux-ext2fs: there is a block count (di_nblocks in ffs[1-2]) that is only 32 bits in ffs1 and in ext2fs (actually it only has 31 bits in ffs1 and in FreeBSD-ext2fs, since it is signed). Fs block numbers in these fs's are also 32 (or 31) bits, but this block counter doesn't suffice for counting them because it has units of 512-blocks while fs block numbers have larger units. When this block counter overflows, the only (?) thing broken is st_nblocks in stat(2). One way of fixing this is to limit the file size to 1TB - 1. This would also simplify describing the limit. This is only a serious restriction for sparse files. With the default block size of 32K, ffs1 can only handle file systems of size 64TB. It can only handle 1 non-sparse file of size nearly 64TB, or 63 non-sparse files of size 1TB-1. It is now barely reasonable to have non-sparse files of these sizes, but systems with such files probably wouldn't be using ffs1. Sparse files are more interesting. You can fit a large number of sparse files of size 64TB-1 in on a file system of size just a few GB, and also write them in less than a day or two. Also, the potentially-overflowing block counter is for physical blocks, so it can't overflow for fairly sparse files. Thus restricting the file size to 1TB-1 would break some cases unnecessarily. ffs2 generally gives much larger limits for file system sizes but halves the limits for file sizes (since block numbers are twice as large, the block size must be twice as large to fit the same number of block numbers in an indirect block). >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#mount-foreign-fs >> Is this completely true? Should it be updated? This doesn't give much detail, so there is less to go wrong in it. >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#alternate-directory-layout >> Does this still deserve to be listed as a FAQ? I think it never did, since it is about a technical problem that can't really be solved outside of the file system, especially with today's disk sizes allowing 10's if not thousands as many files as when it was written in 1998, or thousands if not millions as many files as when ffs was written in ~1983. With millions of files, you just can't make much difference with a few changes to the directory layout. It was written by mckusick in 1998, so it is also out-of-date with respect to the better layout policies that he implemented in ffs in 2001. BTW, cp(1) still has bogus sorting related to this. It sorts files so that non-directory files are copied before directory files, because it knows too much about ffs's internals and about ffs being the only file system. Perhaps this is still good if the file system is ffs, but I think it is better to preserve any existing order that you get from the command line or from a directory traversal (use fts and specify pre- or post-order). But the sorting function is of low quality and tends to destroy any existing order: - it uses qsort(), which gives an unstable sort for items that compare equal - everything except directories vs non-directories compares equal. The result is that if you have a perfectly sorted list on the command line, say consisting of all regular files in alphabetical order, then the order is very unstable. Except the instability is very stable -- it is usually close to a perfect inversion of the order. Anyway, this instability makes it impossible to either preserve existing orders in file hierarchies or to specify optimal orders on the command line. Bruce