[2821] in linux-scsi channel archive
Re: Problems making big fs on DPT RAID
daemon@ATHENA.MIT.EDU (Michael Neuffer)
Tue Nov 18 00:35:24 1997
Date: Tue, 18 Nov 1997 06:32:55 +0100 (MET)
From: Michael Neuffer <neuffer@goofy.zdv.Uni-Mainz.de>
Reply-To: Michael Neuffer <neuffer@goofy.zdv.Uni-Mainz.de>
To: John Robinson <john@intelligent.co.uk>
cc: Linux SCSI List <linux-scsi@vger.rutgers.edu>
In-Reply-To: <199711172215.WAA23745@irvine.intelligent.co.uk>
On Mon, 17 Nov 1997, John Robinson wrote:
> Just upgraded a 'box with a DPT PM3334UW (SmartRAID IV) to 2.0.31. For
> the first time ever after doing a reboot (i.e. use the 'reboot'
> command) I was told by fsck when restarting that I was mounting a
> filesystem with errors. (Well, no, OK, I've screwed things royally
> before now but that was my fault.) It was a perfectly clean shutdown
> as far as I could see, and it only happened on one of my
> partitions. It actually had no errors on it (according to fsck but I
> couldn't tell you if there are any incorrect sectors; it's my /usr
> partition). I was rebooting to change my CMOS clock (OK so it's not
> necessary but I believe it's more polite when putting it back).
>
> What's going on? Is the card not getting round to flushing its
> write-back cache? Is the driver not telling it to?
> I am using the eata_dma driver. I've incorporated hfs and the teardrop
> patch into my kernel. I have the eata_dma and 3c590 drivers in the
> kernel not as modules. It's a Pentium 200 machine (yup, eagerly
> seeking/awaiting a f00f patch for 2.0.x). Any more info, just ask.
In 2.0.31 fs code lurks a bug that shreddered the fs of more then one
person already. You should upgrade to 2.0.32 immediately since it fixes
this bug and also the teardrop and f00f bugs.
Mike
