Hi,
> > raiddev /dev/md0
> > device /dev/sda2
> > device /dev/sdb2
>
> > /dev/hda6 / ext2 defaults 1 1
> > /dev/hda1 /boot ext2 defaults 1 2
> > /dev/hda5 /usr/local/apache/logs ext2 defaults 1 3
> > /dev/md0 /home ext2 defaults,usrquota 1 0
> > /dev/sda1 swap swap defaults 0 0
> > /dev/sdb1 swap swap defaults 0 0
>
> So you do not have any other partitions on sda and sdb which could get checked
> simultaniously. Then my first guess is not the cause it seems.
>
> Did you have a look what flags will be given to fsck at boottime? Try to run it by
> hand with the same flags (it's fsck -C -a -t $type in my case, SuSE 6.3).
>
> Here the '-a' could be the cause for longer checktimes. May there are more tests
> and automtic decisions involved that way.
>
> -a Automatically repair the file system without any
> questions (use this option with caution). Note
> that e2fsck(8) supports -a for backwards compati
> bility only. This option is mapped to e2fsck's -p
> option which is safe to use, unlike the -a option
> that most file system checkers support.
>
> If that runs also much faster if you run it by hand then at bootime I've no idea
> anymore I fear.... And maybe somebody else on the list knows something.
I will try to play with next time the server crash. Also maybe it is
because of the reconstruction is done in the same time that the fsck.
thx for help
Octave
Amicalement,
oCtAvE
"Internet ? Welcome in the slave economy."