> the disk's sector remapping is > invisible outside of the disk. Not if the disk makes some of the info available through the smart interface, as it seems to do.
> No. Think about it. If you read the sector and get an error, where are > you going to get a good copy of the data from Read another 250 times. If one of them succeeds you have your data. That's why I said *final* read error, that's when the disk gives up after having tried hundreds of times. Currently I have a disk where one block fails a read permanently while another is readable eventually. > remapping and write the data out to a good sector? On write failures, > the drive has the data in a buffer Chances of detecting a write failure aren't that high - the magnetisation of the track would have to be seriously damaged, such that head tracking fails. If you just write out a stream of bits over a magnetic surface, you have no way of knowing if magnetistion (and therefore write) occured correctly until after you have read it back in again. Verify of all written blocks won't happen. Yes I have thought about it :) It's very similar to the old 5 1/4" floppies. You can write as much as you want, doesn't mean the data is correctly recorded. Does anyone notice? Nope, that's why floppies were copied with a verify run after writing. Takes twice as long. > If you go back and read your original post, you gave no information at > all about what had changed on your system recently. Because after assessing the situation I decided none of the changes were relevant. The question "how do I find file X which occupies block N" is not answered by what software versions I'm running. > Having the LBA address won't tell you which file is affected. But it's plenty enough to do the block read test you suggested in that paragraph. :) > And you're right, you don't need to spend heaps of time with debug.*fs > if you stopped caring about which file was affected after asking how to > find it out... at which point this whole thread becomes pointless. True, though we branched off a bit. It was interesting to find the file if the cost is ok, but when I asked I didn't know the cost was too high. > How, exactly, will the kernel know when the boot sequence has begun and > ended? Well I thought that would be simple as: If 10 block transfers with DMA have gone through fine, it's pretty well not the DMA which is suddenly going to fix a media problem, is it? And if a bus reset is necessary, fine - but please restore to previous state. I know how to deal with DMA, Joe User doesn't. It's a usability issue. > Turning DMA off during recovery makes the recovery easier and more > likely to succeed. This fact has been determined by people who have a > clue about how IDE works. Sure. And the Linux kernel doesn't have and never had design and programming shortcomings, no.... Come off it. There are plenty of things which are sub-optimal in the kernel, there are plenty of bugs left, and no doubt there are plenty of things which aren't implemented yet. I keep on hearing that the SCSI implementation is pretty bad, certainly wrt to error handling. And when an unreadable cd block deadlocks the kernel, then either IDE error recovery is somewhat shaky, or the drive is flawed. I'm not discounting either possibility (and the drive was not the cheapest). Perhaps this thread has reached EOL now... Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
