Date: Wed, 14 Dec 2011 14:03:49 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= <olivier@cochard.me> Cc: freebsd-bugs@freebsd.org Subject: Re: bin/162659: Can' t install FreeBSD-amd64-9.0-RC2 on disk less than 6Go (/mnt: out of inodes) Message-ID: <20111214125712.P1950@besplex.bde.org> In-Reply-To: <201112131030.pBDAUDCI065085@freefall.freebsd.org> References: <201112131030.pBDAUDCI065085@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1935079863-1323831829=:1950 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 13 Dec 2011, [ISO-8859-1] Olivier Cochard-Labb=E9 wrote: > The following reply was made to PR bin/162659; it has been noted by GNATS= =2E THe following reply probably won't be noted by gnats, since gnats created an incomplete Cc list as usual. > I've did some tests: The number of inode after a fresh install of > 9.0-RC2 is half the number of inode after the fresh install of a 8.2. > I've install a 6Gio hard drive, MBR, no swap partition and all in / > (under VirtualBox). 9.0 has the dubious change of increasing the default block size in newfs from 16K to 32K (and, correspondingly, increasing the default fragment size from 2K to 4K). It is missing the corresponding change of increasing the number of fragments per inode (NFPI) from 4 to 8. Thus if you blindly accept the newfs defaults, you get half as many inodes as before. Increasing the default block size is dubious because vfs is still tuned for a block sizes of at most 16K. (See BKVASIZE in <sys/param.h>.) Also, I don't buy the reason for increasing the default. newfs's default block/fragment sizes went through 1 previous round of doubling in FreeBSD, from 8K/1K to 16K/2K in 2001. NFPI was not doubled then either, but the problem was less noticeable because NFPI was really too high for 8K/1K. I have always used -i 8192 in my shell script for creating ffs file systems. This corresponds to NFPI =3D 8 for a fragment size of 1K. When the default fragment size changed from 1K to 2K, -i 8192 became the default, but I didn't change my script. The number of files (and thus the number of inodes needed) doesn't change when the fragment size changes (except large fragments limit the number of files by wasting space). It changes with usage, but probably not as fast as the most efficient block size, especially for program source files. BKVASIZE and its comment are poorly maintained and haven't even caught up with the previous round of doubling in newfs: - when BKVASIZE was added in 1996, it was only 8192, and there was a DFLTBSIZE parameter with a bogus value of 4096 (4096 is bogus because it is the minimum block size in ffs, but the default block size in newfs has never been that small in FreeBSD). 8192 was adequate for the newfs default, but left no room for expansion. - in 2000, BKVASIZE was doubled to give space for expansion. This was just in time for the doubling of the newfs default, though too late for users who didn't use the newfs default. The safety factor of 2x was documented in a comment by claiming that 16384 is roughly 2x the block size used by a normal UFS file system. - BKVASIZE and its comment weren't changed when newfs's default block size was doubled in 2001, so there was no safety factor and the comment about it was off by a factor of 2. - BKVASIZE and its comment weren't changed when newfs's default block size was doubled in 2011, so there is an inverse safety factor and the comment about it is off by a factor of 4. BKVASIZE can't simply be doubled from 16K even once, since arches with limited address spaces can't fit much more. Bruce --0-1935079863-1323831829=:1950--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111214125712.P1950>