On Mon, 2004-09-06 at 13:30, Steve Gehlbach wrote:
> However, in the logs I see this:
>
> Sep 6 11:12:51 server70 kernel: hdc: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Sep 6 11:12:51 server70 kernel: hdc: dma_intr: error=0x40 {
> UncorrectableError }, LBAsect=46724440, sector=46724352
> Sep 6 11:12:51 server70 kernel: end_request: I/O error, dev 16:01 (hdc),
> sector 46724352
> Sep 6 11:12:53 server70 kernel: hdc: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Sep 6 11:12:53 server70 kernel: hdc: dma_intr: error=0x40 {
> UncorrectableError }, LBAsect=46724440, sector=46724360
> Sep 6 11:12:53 server70 kernel: end_request: I/O error, dev 16:01 (hdc),
> sector 46724360
> Sep 6 11:12:55 server70 kernel: hdc: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Sep 6 11:12:55 server70 kernel: hdc: dma_intr: error=0x40 {
> UncorrectableError }, LBAsect=46724440, sector=46724368
> Sep 6 11:12:55 server70 kernel: end_request: I/O error, dev 16:01 (hdc),
> sector 46724368
> Sep 6 11:12:56 server70 kernel: hdc: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Sep 6 11:12:56 server70 kernel: hdc: dma_intr: error=0x40 {
> UncorrectableError }, LBAsect=46724440, sector=46724376
> Sep 6 11:12:56 server70 kernel: end_request: I/O error, dev 16:01 (hdc),
> sector 46724376
>
> So maybe it is an HDD failure? The ide interface otherwise seems okay to
> the hda disk.
It definitely looks like a disk error.
> I can mount the drive RO and get data in many places; I have an image
> that is two months old so it is not so bad. But I was surprised to see
> fsck give up. After 25 years of Unix, Sun, and Linux, this the first
> time I have seen fsck give up.
There are some things that jfs's fsck doesn't fix that it should be able
to fix, but it isn't going to be able to recover when there are
excessive I/O errors from the disk.
> Usually it spews inodes but corrects
> them, which usually means loss of data but still the disk is then
> mountable r/w.
> >>I thought _journaling_ filesystems could roll back
> >>transactions and
> >>recover from structural problems.
The journaling doesn't exactly roll back transactions. It makes the
transaction atomic, such that either every part of the transaction gets
committed to disk, or none of it does. The journaling is meant to
prevent structural damage due to a system crash or power loss, not
really to recover if some kind of damage is introduced, either by
hardware failure or software bugs. That is fsck's job, but it's
independent of the journaling.
Shaggy
--
David Kleikamp
IBM Linux Technology Center
_______________________________________________
Jfs-discussion mailing list
[EMAIL PROTECTED]
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
