From: Martin Dalecki <dalecki@evision-ventures.com>
To: Andries.Brouwer@cwi.nl
Cc: akpm@zip.com.au, daniel@rimspace.net, linux-kernel@vger.kernel.org
Subject: Re: 2.5.12 severe ext3 filesystem corruption warning!
Date: Thu, 02 May 2002 22:50:32 +0200 [thread overview]
Message-ID: <3CD1A698.80408@evision-ventures.com> (raw)
In-Reply-To: <UTC200205022140.g42Le8N14139.aeb@smtp.cwi.nl>
Użytkownik Andries.Brouwer@cwi.nl napisał:
>>>2.5.12, serious ext3 filesystem corrupting behavior
>>
>
> I have had problems with 2.5.10 (first few blocks of the root
> filesystem overwritten) and then went back to 2.5.8 that I had
> used for a while already, but then also noticed corruption there.
> Back at 2.4.17 today..
>
> In my case the problem was almost certainly the IDE code.
> More in particular, the 2.5.8 corruption happened on four
> different occasions, on two different disks, hanging off
> an HPT366 that is without problems on 2.4*. Three of the
> four times there were messages like
Hmm... let me assume that you are using UDMA on all those drives.
Since you have apparently a system with quite a lot of
different simultanecousy active drives in them it could be very well possible
that the code that determined the do_request drive selection strategy
was the cause of your problems. It could very well be that
the recent changes with respect to this actually could have cured
this. (2.5.8 is the time around where die PADAM_ tags got introduced
there.
> Apr 29 15:26:00 kernel: hde: task_out_intr: status=0x51 { DriveReady SeekComplete Error }
> Apr 29 15:26:00 kernel: hde: task_out_intr: error=0x04 { DriveStatusError }
>
> May 2 01:21:23 kernel: hdf: status error: status=0x50 { DriveReady SeekComplete }
> May 2 01:21:23 kernel: hdf: no DRQ after issuing WRITE
> May 2 01:21:37 kernel: hdf: task_out_intr: status=0x51 { DriveReady SeekComplete Error }
> May 2 01:21:37 kernel: hdf: task_out_intr: error=0x04 { DriveStatusError }
>
> Each time some data was written at a wrong address on disk.
> Now these are ext2 filesystems, so I noticed.
> Elsewhere I have ext3 and reiserfs, but journalling does not
> protect against IDE drivers that write stuff to the wrong disk block.
next prev parent reply other threads:[~2002-05-02 21:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-02 21:40 2.5.12 severe ext3 filesystem corruption warning! Andries.Brouwer
2002-05-02 20:50 ` Martin Dalecki [this message]
2002-05-02 21:58 ` Andrew Morton
2002-05-02 22:57 ` Daniel Pittman
2002-05-04 5:26 ` Milton Miller
2002-05-04 5:46 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2002-05-02 13:01 Daniel Pittman
2002-05-02 19:21 ` Andrew Morton
2002-05-02 19:34 ` Alexander Viro
2002-05-02 20:34 ` Andrew Morton
2002-05-02 22:39 ` Daniel Pittman
2002-05-02 22:37 ` Daniel Pittman
2002-05-02 23:00 ` Andrew Morton
2002-05-03 0:02 ` Daniel Pittman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CD1A698.80408@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=akpm@zip.com.au \
--cc=daniel@rimspace.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox