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@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- 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:-)
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
