On Mon, Apr 4, 2011 at 5:11 PM, Kevin Chadwick <[email protected]> wrote: > On Thu, 31 Mar 2011 12:46:06 +0200 > Otto Moerbeek wrote: > >> > In general, the default values and algorithms for allocations could >> > probably do with a tune-up, since of course today's disks are several >> > magnitudes larger than only a few years ago (let alone than those that >> > were around when the bulk of the file system code was written!), and the >> > usage patterns are also in my experience often wildly different in a >> > large file system than in a smaller one. >> >> We do that already, inode density will be lower for newly created >> partitions, because diskalbel sets larger block and fragment sizes. > > When creating filesystems with a partition containing many small files > like one containing Maildirs. Is it a good idea during installation to > set frag-size in disklabel to 1024 in order to automatically increase > the number of inodes as oppose to simply using newfs -i 4096? Or would > it reduce performance for larger files unnecessarily.
If you have gigabytes and gigabytes of mail, it's a reasonable bet that some of them are going to be larger mails. The most effort I would generally advise spending on this is monitoring free inodes, and if it looks like you'll run out, backup and restore during an upgrade. > I was also expecting -g avgfilesize flag to affect the number of inodes > but it doesn't and it is useable with tunefs. Would anyone mind > telling me what affect it has? It affects allocation policy only. Leave it alone. Seriously, all these knobs come from an era when hard drive sizes were measured in megabytes. It's time to move on.
