From: Steven Poulakos <poulakos@uiuc.edu>
To: Reiserfs Mailinglist <reiserfs-list@namesys.com>
Subject: Fatal File System Corruption -Software RAID + NFS
Date: Sun, 16 Nov 2003 11:04:00 -0600 [thread overview]
Message-ID: <3FB7AE00.4070409@uiuc.edu> (raw)
Hi,
I'm encountering my second wave of reiserfs filesystem corruption with a
Web/NFS/NIS server. This time, I had fatal corruption after updating
the Kernel. Below are the system specs and the error message that I'm
receiving.
The system:
Debian (latest unstable)
2.4.22 Kernel (not patched in any way)
running NFS (from the kernel), which serves home directories to 3
workstations
Software RAID 1
-2, mirrored 80gig (7200RPM) IBM hard drives
-Each drive is connected to its own channel on a Promise Ultra ATA/100
Controller (Ultra100 Tx2) card (PCI) (using ATA 100 cables)
-the two drives are called hda and hdc (contain 3 mirrored RAID partitions)
The problem:
Two of three RAID'ed partitions have been working without errors (/home
and /usr). My root partition generated the errors below for many days
until detected. After a reboot, the system would not load. reiserfsck
--rebuild-tree could not recover the corruption. I have assumed that I
must rebuild the system now, and being able to prevent the errors below
from happening again will affect how I proceed with the rebuild. Any
info for prevent the below errors would be great!
-Steve
Here are snippets of the errors that just repeat over and over...
Nov 9 06:47:34 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Nov 9 06:47:34 ctdev kernel:
Nov 9 06:47:34 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:47:34 ctdev kernel:
Nov 9 06:47:34 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:47:34 ctdev kernel:
Nov 9 06:47:39 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:47:39 ctdev kernel:
Nov 9 06:47:39 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:47:39 ctdev kernel:
Nov 9 06:47:44 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:47:44 ctdev kernel:
Nov 9 06:47:44 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
.....(snip).......
.....(snip).......
Nov 9 06:47:59 ctdev kernel:
Nov 9 06:48:05 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:48:05 ctdev kernel:
Nov 9 06:48:05 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:48:05 ctdev kernel:
Nov 9 06:48:05 ctdev kernel: hdc: status timeout: status=0xd0 { Busy }
Nov 9 06:48:05 ctdev kernel:
Nov 9 06:48:05 ctdev kernel: PDC202XX: Secondary channel reset.
Nov 9 06:48:05 ctdev kernel: ide1: reset: success
Nov 9 06:48:10 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:48:10 ctdev kernel:
Nov 9 06:48:10 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:48:10 ctdev kernel:
Nov 9 06:48:10 ctdev kernel: hdc: write_intr error1: nr_sectors=5,
stat=0xd0
Nov 9 06:48:10 ctdev kernel: hdc: write_intr: status=0xd0 { Busy }
Nov 9 06:48:10 ctdev kernel:
Nov 9 06:48:10 ctdev kernel: PDC202XX: Secondary channel reset.
Nov 9 06:48:10 ctdev kernel: ide1: reset: success
Nov 9 06:48:15 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
.....(snip).......
.....(snip).......
Nov 9 06:56:45 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:56:45 ctdev kernel:
Nov 9 06:56:50 ctdev kernel: hdc: write_intr error1: nr_sectors=51,
stat=0xd0
Nov 9 06:56:50 ctdev kernel: hdc: write_intr: status=0xd0 { Busy }
Nov 9 06:56:50 ctdev kernel:
Nov 9 06:56:50 ctdev kernel: PDC202XX: Secondary channel reset.
Nov 9 06:56:50 ctdev kernel: ide1: reset: success
Nov 9 06:56:56 ctdev kernel: hdc: write_intr error1: nr_sectors=51,
stat=0xd0
Nov 9 06:56:56 ctdev kernel: hdc: write_intr: status=0xd0 { Busy }
Nov 9 06:56:56 ctdev kernel:
Nov 9 06:56:56 ctdev kernel: PDC202XX: Secondary channel reset.
Nov 9 06:56:56 ctdev kernel: ide1: reset: success
Nov 9 06:56:56 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:56:56 ctdev kernel:
Nov 9 06:57:01 ctdev kernel: hdc: status error: status=0x58 {
DriveReady SeekCo
mplete DataRequest }
Nov 9 06:57:01 ctdev kernel:
..... (snip) .....
next reply other threads:[~2003-11-16 17:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-16 17:04 Steven Poulakos [this message]
2003-11-16 19:28 ` Fatal File System Corruption -Software RAID + NFS Christian Kujau
2003-11-17 14:47 ` Dan Oglesby
2003-11-17 17:00 ` Steven Poulakos
2003-11-17 20:58 ` Christian Kujau
2003-11-20 19:59 ` Steven Poulakos
2003-11-20 8:20 ` Hans Reiser
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=3FB7AE00.4070409@uiuc.edu \
--to=poulakos@uiuc.edu \
--cc=reiserfs-list@namesys.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.