Re: Problem repairing filesystem

[Seth Mos <knuffie@xxxxxxxxx>]

At 15:38 14-8-2002 +0200, Paul Schutte wrote:
> software RAID5 with internal log using  postmark v1.5
> Time:
>         6186 seconds total
>         5840 seconds of transactions (17 per second)

Seems reasonable for an internal log. You could try the new software raid 
with the v2 logging code which should prove a big help.

> hardware raid5 using postmark v1.5:
> Time:
>         749 seconds total
>         709 seconds of transactions (141 per second)
>
>
> Good question.
> That was the whole idea, but I it did'nt work out in practice.
> I am not sure why.

I think it is the drive write caching. Someone with a 3ware raid controller 
also had problems with data corruption after poweroff. Older 3ware 
controllers had problems with disk failures in raid5 and corruption. I am 
not that familiar with the adaptec controller though, maybe I'm paranoid.

> > I understand that the machine did not boot anymore after the crash? Can it
> > be that the drive had write caching which made it fail horribly in the end
> > and crashed the machine?
>
> The controller was set not to cache writes, but I don't know what the
> controller did with each drive.

If it doesn't disable the write cache of the drive the raid5 is just a 
useless as using the controller caching without the battery backup.

> It never lost power, so write caching should not be a problem.
> It took 2 days to get the new harddisk and only then did we switch it off.

If the disk failed to write the contents which could be in the onboard 
buffer the controller alreay would have signalled the OS that data was 
succesfully written while in fact it was working with a in memory (controller)

> It did boot, but crashed almost immediatly.
> You can't repair a xfs root partittion without a rescue disk and therefore
> the nfs trick.

I commonly use the Linuxcare boot disk since it is small and has all the 
utilities I need. And I can copy a newer xfs_repair over by using scp. Same 
goal different method :-)

> Was the kernel running. It was 1-1 backported to 2.4.9 by SGI ?

I actually meant the 2.4.18 release but I don't know about the other, I 
guess that once was an errata kernel.

Cheers
--
Seth
It might just be your lucky day, if you only knew.