>> 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). >
Stuart, Thanks for the tip. But I can verify when I did lookup my 80G filesystem it is currently not specifying -i, so it is 8Kb per a single inode (it is 4 times frag size per your update to newfs man page). This is a no brainer optimization which can get huge wins in fsck immediately without too much change in the existing code. Otto, In my tests on AMD64, if FFS partition size increases beyond 30GB, fsck starts taking exponential time even if you have zero used inodes. This is a for i () for j() loop and if you reduce the for j() inner loop it is a win. dumpfs -m /downloads # newfs command for /dev/wd0o newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s 172714816 /dev/wd0o So, if I read it correctly, setting just the block size higher to say 64Kb does auto tune frag size to 1/8 which is 8Kb (newfs complains appropriately) but the auto tune inode length to 4 times frag which is 32Kb is not implemented now? Is this the proposed formula? If a user tunes -i inodes, or -f frags or -b block size, it should all auto-adjust to the same outcome based on above formula in the future? dumpfs doesn't show the total inodes or the inode length in a easily readable format (-m option). Just trying to understand what the acronyms mean. Thanks > disklabel has code already to move to larger block and frag sizes for > large (new) partitions. newfs picks these settings up. > > >> >> 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. > > -Otto
