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.
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
