From: Davis M. <da...@co...> - 2004-09-25 04:14:59
|
Computer-Help.Net Answers that work.=20 =20 =20 =20 =20 September 24, 2004 =20 =20 Bruce, I fell upon SmartMonTools while searching for a low level ATA = command utility as I would like to attempt to force failed hard disks to = simply give me what they could. I also intend to test it on several Win32 systems to see if it is = suitable for "average end users" who, unfortunately wind up holding the = bag when there is no good reason for M$ not to have included some = warning prior to the catastrophic failure that too often bankrupts small = companies, literally. At any rate, I wanted to tender a technique I have been using = since the 1980's to either repair bad ECC's or to confirm media damage. = More often than not, it has also resulted in the data being good. The tool I use is Norton Diskedit; though the principle should = work with virtually any program. After locating the erroring sector using another utility, I = migrate to the location with NU in physical disk mode and after telling = it to ignore the error, simply rewrite the sector. If the damage is = physical, it remains an error; if it was software induced (i.e. system = crash or power failure), the rewrite corrects the ECC and the error is = gone. (as an aside, I now wonder whether I have caused a sector = realocation in some cases; but those didn't exist when I first started = using the technique) I do not know if this has any direct bearing on your specific = project; but, wanted to, at least, qualify one of your assertions and, = perhaps influence others that might encounter your project or those who = may be working with you. I have seen tens of thousands of hard drives with bad sectors and = most of them were not due to media damage. It isn't supposed to be = possible to interrupt the drive in mid sector; but it happens regularly. If you have any questions or problems, please feel free to contact = me by Email or by phone. Sincerely, Davis M McCarn Computer-Help.Net 184 Eaglecrest Drive Matthews, NC 28104 (704) 882-7551 or Email: da...@co... =20 =A9 Davis M McCarn 2004 All Rights Reserved =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 |
From: Volker K. <lis...@pa...> - 2004-09-25 23:24:47
|
> no good reason for M$ not to have included some warning prior to the > catastrophic failure that too often bankrupts small companies, literally. Do they deserve much sympathy when they can't spell "b a c k u p"? This is not M$'s fault. There is no guarantee that there will be any warning before the disk self-destructs. > After locating the erroring sector using another utility, I > migrate to the location with NU in physical disk mode and after > telling it to ignore the error, simply rewrite the sector. This would fix any read errors not caused by bad surface. It also destroys the data, but that's no loss as it's unreadable anyway. Reading all the disk and writing it back is a one-liner on the shell in unix, though to make it efficient would cost a little more effort (10 lines?). The easiest on Linux would be to run badblocks in non-destructive write-mode, which writes writes each block at least once, leaving the data unchanged. I would rely on the disk's selftest; if it says "foobared" and the disk is under warranty, I won't waste my time. If the warranty is out, there's nothing to lose with a destructive badblocks test, cat /dev/zero >/dev/hdX, or simply reformatting, though it begs the question whether it's worth risking any more time on this disk. If the selftest is fine, nulling out the disk is always a good idea. The by far best program I've seen for rescuing data from failing disks is dd_rescue. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. |
From: Volker K. <lis...@pa...> - 2004-09-26 00:52:57
|
Hi Davis, I reply to list again, assuming that's where your reply was meant for. > Recently, I have seen a string of data recoveries where the logs kept by the > O/S detected problems or the initial failure occurred weeks or months before > the catastrophic failure. That certainly says there's room for improvement in the OS, but doesn't absolve of keeping backups. > > This would fix any read errors not caused by bad surface. It also > > destroys the data, but that's no loss as it's unreadable anyway. > > As I said in my original post to you, the data is often read correctly! I > have had it in the middle of text files where it was obvious, as well as in > executables (though I will always replace the executable) There is no > guarantee, but statistically it is read correctly even though the ECC is > wrong. Ah, I misunderstood. You're saying that despite the drive returning an ECC error, it still delivers the correct block data with the error? Interesting, I just assumed the return data would be random or nulled. I wonder whether badblocks writes that same data back, and whether dd returns the data with the error. Do you know? I doubt about dd. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. |
From: Bruce A. <ba...@gr...> - 2004-09-26 06:38:38
|
Davis, On Fri, 24 Sep 2004, Davis McCarn wrote: > I fell upon SmartMonTools while searching for a low level ATA > command utility as I would like to attempt to force failed hard disks > to simply give me what they could. > I also intend to test it on several Win32 systems to see if it > is suitable for "average end users" who, unfortunately wind up holding > the bag when there is no good reason for M$ not to have included some > warning prior to the catastrophic failure that too often bankrupts > small companies, literally. > At any rate, I wanted to tender a technique I have been using > since the 1980's to either repair bad ECC's or to confirm media > damage. More often than not, it has also resulted in the data being > good. > The tool I use is Norton Diskedit; though the principle should > work with virtually any program. > After locating the erroring sector using another utility, I > migrate to the location with NU in physical disk mode and after > telling it to ignore the error, simply rewrite the sector. If the > damage is physical, it remains an error; if it was software induced > (i.e. system crash or power failure), the rewrite corrects the ECC and > the error is gone. (as an aside, I now wonder whether I have caused a > sector realocation in some cases; but those didn't exist when I first > started using the technique) > I do not know if this has any direct bearing on your specific > project; but, wanted to, at least, qualify one of your assertions and, > perhaps influence others that might encounter your project or those > who may be working with you. > I have seen tens of thousands of hard drives with bad sectors > and most of them were not due to media damage. It isn't supposed to > be possible to interrupt the drive in mid sector; but it happens > regularly. > If you have any questions or problems, please feel free to > contact me by Email or by phone. Dear Davis, This is VERY useful, thank you! The number of Windows users of smartmontools is definitely increasing and I was hoping that at some point someone would tell us how to force sector rewrites or reallocation under Windows. What you say above makes complete sense, as a technique to re-write or overwrite bad sectors. The only additional thing that would be useful to know (and perhaps NU just tells you this, and it's obvious, so you didn't mention it) is to understand WHCIH FILE contains a given unreadable or bad ECC block. Would you be willing to help me revise http://smartmontools.sourceforge.net/BadBlockHowTo.txt with information for Windows users (or, if you prefer, write a separate short howto for Windows)? I'd be delighted to post it, and think it would help many people. The single most useful thing for many users would be a 'transcript' showing the operations necessary to overwrite a sector for one example of a failed disk read. Cheers, Bruce |