On Thu, Mar 31, 2011 at 12:30:29PM +0200, Benny Lofgren wrote:
> On 2011-03-31 11.13, Stuart Henderson wrote:
> > On 2011-03-31, Otto Moerbeek <o...@drijf.net> wrote:
> >> On Wed, Mar 30, 2011 at 03:45:02PM -0500, Amit Kulkarni wrote:
> >>> In fsck_ffs's pass1.c it just takes forever for large sized partitions
> >>> and also if you have very high number of files stored on that
> >>> partition (used inodes count goes high).
> > If you really have a lot of used inodes, skipping the unused ones
> > isn't going to help :-)
> > You could always build your large-sized filesystems with a larger
> > value of bytes-per-inode. newfs -i 32768 or 65536 is good for common
> > filesystem use patterns with larger partitions (for specialist uses
> > e.g. storing backups as huge single files it might be appropriate
> > to go even higher).
> > Of course this does involve dump/restore if you need to do this for
> > an existing filesystem.
> >> It is interesting because it really speeds up fsck_ffs for filesystems
> >> with few used inodes.
> >> There's also a dangerous part: it assumes the cylinder group summary
> >> info is ok when softdeps has been used.
> >> I suppose that's the reason why it was never included into OpenBSD.
> >> I'll ponder if I want to work on this.
> >
> > A safer alternative to this optimization might be for the installer
> > (or newfs) to consider the fs size when deciding on a default inode
> > density.
>
> I think this is a very good idea regardless. I often forget to manually
> tune large file systems, and end up with some ridiculously skewed
> resource allocations.
>
> For example, this is what one of my file systems looks like right now:
>
> skynet:~# df -ih /u0
> Filesystem Size Used Avail Capacity iused ifree %iused
> Mounted on
> /dev/raid1a 12.6T 7.0T 5.5T 56% 881220 211866810 0% /u0
>
> This one takes about an hour to fsck.
>
> 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.
-Otto
>
> I guess an fs like the one above would benefit a lot from the optimization
> the OP mentions.
>
> Perhaps it could be optional, since Otto mentions that it makes
> assumptions on correctness of the cylinder group summary info. I haven't
> looked at the code in a while, so I can't really judge the consequences
> of that, or if some middle ground can be reached where the CG info is
> sanity checked without the need for a full scan through every inode.
>
>
> Regards,
> /Benny
>
> --
> internetlabbet.se / work: +46 8 551 124 80 / "Words must
> Benny Lvfgren / mobile: +46 70 718 11 90 / be weighed,
> / fax: +46 8 551 124 89 / not counted."
> / email: benny -at- internetlabbet.se
