On Thu, Mar 27, 2008 at 4:40 PM, Michael Hannon <[log in to unmask]> wrote:
> On Thu, Mar 27, 2008 at 05:06:53PM +0100, [log in to unmask] wrote:
>  > On Thu, 27 Mar 2008, Stephen John Smoogen wrote:
>  .
>  .
>
> .
>  > Hmm, we successfully fsck'd ext3 filesystems 1.4 TB in size frequently a
>  > couple of years ago, under 2.4 (back then, it was SuSE 8.2 + a vanilla
>  > kernel). This took no more than a few hours (maybe 2,3, or 4).  It was
>  > hardware RAID, not too reliable (hence "frequently"), and not too fast (<
>  > 100 MB/s). A contemporary linux server with software RAID should complete
>  > an fsck *much* faster, or something is wrong.
>
>  Hi, Stephan.  Yea, I think I must be doing something wrong here, but I
>  haven't been able to figure out what it is.
>

Well this could be a hardware error on the wire (bad scsi wire etc).
It could also depend on how the data is laid out on the disk. The long
fsck's were tons of directories and files.. and they were read,
deleted, etc in random order (eg INN news). but then again it could be
that I had crap hardware then too :).

>
>  > And I still wonder why fsck at at all just because a broken disk was
>  > replaced in a redundant array?
>
>  The system seems to insist on it.  Again, there may be some cockpit
>  error involved.
>

Usually it will require an fsck if the disk did not shutdown clearly
or some other issue it is detecting. I would need to know more about
the hardware in place (controller, number of drives, type of drives,
how many spares etc) to make a more educated guess.



-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"