2:32 p.m.
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?
--
Chuck Forsberg caf(a)omen.com www.omen.com 503-614-0430
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231 FAX 629-0665
6:21 p.m.
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.
poc
7:11 p.m.
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
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
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
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.
--
T o m M i t c h e l l
Looking for a place to hang my hat.
8:29 p.m.
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(a)coco.merseine.nu Z1aaaaaaa(a)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:-)
8:36 a.m.
On Mon, 2008-07-28 at 09:29 +0800, John Summerfield wrote:
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.
I'm not sure that's true. I've definitely seen boot-time messages along
the lines of "mount count exceeded; performing fsck", and I never change
the defaults.
poc
8:46 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrick O'Callaghan wrote:
On Mon, 2008-07-28 at 09:29 +0800, John Summerfield wrote:
> 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.
I'm not sure that's true. I've definitely seen boot-time messages along
the lines of "mount count exceeded; performing fsck", and I never change
the defaults.
It is true for file systems that anaconda creates. The installer does
the equivalent of "tune2fs -c0 -i0" on the file systems that it creates.
If you are creating file systems post-install with mkfs/mke2fs then this
step needs to be done manually. This is usually the cause of "maximal
mount count reached.." and "/dev/blah has not been checked in XX days"
messages on Red Hat systems that I've come across.
Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkiNzcYACgkQ6YSQoMYUY94pNQCfb0F/yysghsDiinw2If6m67ZR
Kx4AoNy8oXf8kQG8tMmEC/QvYPfGZhbI
=JYbd
-----END PGP SIGNATURE-----
10:27 a.m.
On Mon, 2008-07-28 at 14:46 +0100, Bryn M. Reeves wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrick O'Callaghan wrote:
> On Mon, 2008-07-28 at 09:29 +0800, John Summerfield wrote:
>> 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.
>
> I'm not sure that's true. I've definitely seen boot-time messages along
> the lines of "mount count exceeded; performing fsck", and I never change
> the defaults.
It is true for file systems that anaconda creates. The installer does
the equivalent of "tune2fs -c0 -i0" on the file systems that it creates.
If you are creating file systems post-install with mkfs/mke2fs then this
step needs to be done manually. This is usually the cause of "maximal
mount count reached.." and "/dev/blah has not been checked in XX days"
messages on Red Hat systems that I've come across.
OK, that makes sense.
poc
5755
days inactive
5756
days old
6 comments
5 participants
participants (5)
-
Bryn M. Reeves -
Chuck Forsberg WA7KGX -
John Summerfield -
Nifty Fedora Mitch -
Patrick O'Callaghan