> > Unlikely, at a total of 6 remapped blocks?
>
> Where do you get the figure '6' from?
smartctl -a /dev/hda
> Any value SMART is
> reporting is probably an additional counting scheme, separate from what
> the internal remapping scheme is already using.
That's not how I understand it, but resolving this wouldn't really help.
> So it could be a bug that has existed for a while and the errors have
> begun recently as a result of an interaction between the bug and some
> other change...
That would require another change. Hm. Ok I think there was another
Linux kernel upgrade. Lets not chase the Yeti.
> > something, but it's not a filename. I was hoping for something like
> > find-me-the-filename --lba 0x0067fdcc /dev/hda (and there are several
> > partitions on it)
>
> It's not that simple. You need a filesystem specific tool to work out
> that kind of information--the rest of the system has no need to know
> where the file is on disk.
Sure, but that doesn't mean it's impossible. Or undesirable :)
Obviously the various file system tools would need to be linked
together. I probably had those ext2 tools in the back of my mind.
Anyways, I did a dd if=/dev/hda of=/dev/null, and there are 2 errors on
the disk, one recoverable, the other not. Location as recoreded in the
syslog is exactly the same as recorded by smartmontools (ok, the disk
itself). Seems a clear case now. Unfortunately I don't think the
manufacturer will replace hard disks just because there's one
unrecoverable read error on it. Might have to thrash it a bit...
Here the kernel log:
Jul 30 22:35:43 ruru kernel: hda: dma_intr: status=0x59 { DriveReady SeekComplete
DataRequest Error }
Jul 30 22:35:43 ruru kernel: hda: dma_intr: error=0x01 { AddrMarkNotFound },
LBAsect=6815180, high=0, low=6815180, sector=6814976
[3 more]
Jul 30 22:35:47 ruru kernel: hda: DMA disabled
Jul 30 22:35:47 ruru kernel: hdb: DMA disabled
Jul 30 22:35:47 ruru kernel: ide0: reset: success
This also shows the stupidity the Linux kernel exhibits when trying to
be smart with hard disks which may not be capable of DMA: turn off DMA
permanently and see if it works better. Fine during boot, plain stupid
a few hours later. And gee thanks for turning DMA off on my dvdrom
drive too. 2.6 is no better than 2.4 here. In some aspects Linux can
compete quite well with Redmond. Joe Newbie would now complain about an
almost unusably slow system which can't burn CDs any more (or something
like that).
Here the log which goes with dd terminating with I/O error:
Jul 30 22:01:51 ruru kernel: hda: dma_intr: status=0x59 { DriveReady SeekComplete
DataRequest Error }
Jul 30 22:01:51 ruru kernel: hda: dma_intr: error=0x40 { UncorrectableError },
LBAsect=101401164, high=6, low=737868, sector=101400912
Jul 30 22:01:51 ruru kernel: end_request: I/O error, dev hda, sector 101400912
Jul 30 22:01:51 ruru kernel: Buffer I/O error on device hda, logical block 12675114
[increasing "sector" numbers, due to read-aheahd I guess]
Jul 30 22:02:30 ruru kernel: hda: dma_intr: status=0x59 { DriveReady SeekComplete
DataRequest Error }
Jul 30 22:02:30 ruru kernel: hda: dma_intr: error=0x40 { UncorrectableError },
LBAsect=101401164, high=6, low=737868, sector=101401160
Jul 30 22:02:30 ruru kernel: end_request: I/O error, dev hda, sector 101401160
Jul 30 22:02:30 ruru kernel: Buffer I/O error on device hda, logical block 12675145
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
