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

Reply via email to