Quadratic fsck

[John Summerfield]

Nifty Fedora Mitch wrote:
> On Sun, Jul 27, 2008 at 06:51:47PM -0430, Patrick O'Callaghan wrote:
>> On Sun, 2008-07-27 at 12:32 -0700, Chuck Forsberg WA7KGX N2469R wrote:
>>> Forced fsck operations on huge filesystems (500GB) are
>>> taking a very long time during bootup.  Some typical
>>> situations:
>>>
>>> /dev/sdb6            448936380 399105212  27026504  94% /w
>>> /dev/sdc2            500028036 444954060  29674008  94% /v
>>> /dev/sdc1            461404200 305735808 132230364  70% /y
>>>
>>> How can I reduce this time?  Would converting these to ext4
>>> speed up fsck?  Is converting to ext4 an option yet?
>>>
>>>  Can something be done in the background
>>> on a mounted file system to check it or at least minimize the
>>> time it takes to run fsck on it?
>> Are you running fsck with every boot? In ext3 this is usually
>> unnecessary. Most boots use the journal, which is very fast. I have a
>> 500GB filesystem that's over 60% full, and is on an external USB disk so
>> it's not particularly fast, but the check time is only a few seconds.
>>
>> Use tune2fs to adjust the number of mounts to wait before using
>> auto-fsck.
>>
> 
> How is the system halted.
> 
> If ya hit the power/reset button the .autofsck file at the root of

If the system is reset (reset button, power failure) there is no 
.autofsck on that account (but a user might have created one). However, 
the filesystems will be marked "dirty" and so in need of recovery. 
Mostly, that's just replaying journals.

> each will be found and a full fsck done.   It is also possible to have
> fsck run in parallel on some file systems but the I/O hit may limit

Running filesystem checks in parallel on a single drive is a serious 
impairment to expeditious recovery. The seek times will kill you.

Running filesystem checks in parallel on two drives in a single ATA 
interface is of limited, if any, benefit. The ATA interface simply isn't 
capable of handling two drives in parallel.

Running filesystem checks in parallel on two ATA drives on separate 
interfaces is good. It might not take the length of the longest check, 
but it does work well.

Running filesystem checks in parallel on SCSI drives (reportedly) works 
well, but I've not had the chance to try it.

I don't know where SATA sits in this.

> the value of that.   It is also possible that all three were built at
> the same time and as such are now being check at exactly the same time

For years, the default on RH (and successor) systems has been to only do 
filesystem checks if the filesystem is dirty. Checks based on intervals 
and mounts are not done.

> each time....  Adjust the number of mounts count to be n, n+1, n+2... for the auto-fsck
> to trigger on.  As long as the maximum is not insane this is a good
> trick and it also helps N planned reboots later after a power failure
> that would put them back in sync.

I don't think that doing filesystem checks based on days (or mounts) 
since the last one is a good idea. I do not like unexpected surprises 
such as the computer taking ages to reboot when I expect it to be back 
in service in five minutes.

A good alternative is for the system administration to pronounce "all 
servers go down on the second full moon of the month for a scheduled 
filesystem check." Or whenever.




-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)