From: BitBucket <fil...@gm...> - 2009-09-28 21:00:56
|
Hi: OK, got my first bad block/unreadable sector error on a hard disk drive. The Bad block HOWTO for smartmontools" at http://smartmontools.sourceforge.net/badblockhowto.html has very detailed instructions for what to do next -- under Linux. I've searched in vain for an reference to doing the same thing under Windows (Server 2003), though it is on 80?% of the machines today. Any pointers to help would be appreciated. (Great tool) -- Roy Zider |
From: Christian F. <Chr...@t-...> - 2009-09-29 10:12:03
|
BitBucket wrote: > OK, got my first bad block/unreadable sector error on a hard disk > drive. The Bad block HOWTO for smartmontools" at > http://smartmontools.sourceforge.net/badblockhowto.html has very > detailed instructions for what to do next -- under Linux. I've > searched in vain for an reference to doing the same thing under > Windows (Server 2003), though it is on 80?% of the machines today. > > Any pointers to help would be appreciated. > The old MS tool nfi.exe can be used to determine the file affected by a bad block. This useful tool is (carefully hidden :-) in the OEM Support Tools for W2K: http://support.microsoft.com/kb/253066/en-us It still works on XP and 2003. Example: Find volume and file for physical sector (=LBA) 87000000 on first disk: [X:\] nfi \device\harddisk0\dr0 87000000 ***Physical sector 87000000 (0x52f83c0) is in file number 181799 on drive C. \WINDOWS\Installer\1259885.msp $STANDARD_INFORMATION (resident) $FILE_NAME (resident) $DATA (nonresident) physical sectors 86995532-87000499 (0x52f724c-0x52f85b3) A NG article with further info: http://groups.google.com/group/microsoft.public.win2000.file_system/browse_thread/thread/7cd6bbd5fade6590/ > (Great tool) > Thanks :-) Cheers, Christian |
From: BitBucket <fil...@gm...> - 2009-09-29 15:59:40
|
Christian: Did find nfi.exe in my bag of tricks, after rummaging around on my systems. It's only one step, though, since the rest of the story is what to do with the sector/cluster/block whole drive once you've found it. (Windows tools and procedures in this case) For the record, does the internal long test stop at the first unrecoverable read error? Meaning, if there are multiple bad blocks, just clearing one doesn't do the job, since the next one will appear on the next scan. In this case, the internal long test was 80% complete when it emitted the LBA bad block. I'm working through a procedure to follow the next time this happens. Takes a while -- days, in fact, on a 200 GB drive. -- Roy Zider ----- Original Message ----- From: "Christian Franke" <Chr...@t-...> To: "BitBucket" <fil...@gm...> Cc: <sma...@li...> Sent: Tuesday, September 29, 2009 3:11 Subject: Re: [smartmontools-support] Howto Bad Block in Windows BitBucket wrote: > OK, got my first bad block/unreadable sector error on a hard disk > drive. The Bad block HOWTO for smartmontools" at > http://smartmontools.sourceforge.net/badblockhowto.html has very > detailed instructions for what to do next -- under Linux. I've > searched in vain for an reference to doing the same thing under > Windows (Server 2003), though it is on 80?% of the machines today. > > Any pointers to help would be appreciated. > The old MS tool nfi.exe can be used to determine the file affected by a bad block. This useful tool is (carefully hidden :-) in the OEM Support Tools for W2K: http://support.microsoft.com/kb/253066/en-us It still works on XP and 2003. Example: Find volume and file for physical sector (=LBA) 87000000 on first disk: [X:\] nfi \device\harddisk0\dr0 87000000 ***Physical sector 87000000 (0x52f83c0) is in file number 181799 on drive C. \WINDOWS\Installer\1259885.msp $STANDARD_INFORMATION (resident) $FILE_NAME (resident) $DATA (nonresident) physical sectors 86995532-87000499 (0x52f724c-0x52f85b3) A NG article with further info: http://groups.google.com/group/microsoft.public.win2000.file_system/browse_thread/thread/7cd6bbd5fade6590/ > (Great tool) > Thanks :-) Cheers, Christian |
From: Christian F. <Chr...@t-...> - 2009-09-29 18:34:55
|
BitBucket wrote: > Did find nfi.exe in my bag of tricks, after rummaging around on my > systems. It's only one step, though, since the rest of the story is > what to do with the sector/cluster/block whole drive once you've found > it. (Windows tools and procedures in this case) > > AFIAK, the only tool provided by Windows is chkdsk. 'chkdsk /r' would add the bad blocks to the bad cluster table. The Cygwin version of GNU ddrescue may help: 1. Scan disk, record bad sector offsets in disk.log: # ddrescue -v -d /dev/sda /dev/null disk.log 2. Optional: some read retries: # ddrescue -v -d -r 10 /dev/sda /dev/null disk.log 3. Use nfi.exe to check which items are affected by the bad sectors. (Note: disk.log contains byte offsets in Hex, not sector numbers). If only plain files are affected, the following should be safe: 4. Overwrite sectors marked bad ('-') to force reallocation: # ddrescue --fill=- /dev/zero /dev/sdc disk.log Ddrescue works also from a UBCD4Win, it requires only cygwin1.dll in same directory. > For the record, does the internal long test stop at the first > unrecoverable read error? I've seen this behaviour on recent Samsung disks: If a bad block was detected by a long test, a new short or long test aborts immediately unless this block is reallocated. Cheers, Christian |
From: Joe K. <kr...@ni...> - 2009-09-29 19:40:20
|
With modern drives, bad blocks are handled internally. The block will stay stuck as unreadable until you overwrite it with new data. Then, the driver will internally mark it as bad, and allocate a spare block to take it's place. I don't know how Windows handles blocks, but it may be sufficient to delete the bad file. Ideally, the next access to the bad block will be a write operation. Drive self-tests will stop at a single error. When that happens, it is best to do a read of the entire disk, flagging blocks that give I/O errors. With drives modern drives getting huge capacities, I expect that an occasional lost block will be more common. Hopefully, the OS'es will get better at handling damaged blocks. Joe Krahn BitBucket wrote: > Christian: > > Did find nfi.exe in my bag of tricks, after rummaging around on my > systems. It's only one step, though, since the rest of the story is > what to do with the sector/cluster/block whole drive once you've found > it. (Windows tools and procedures in this case) > > For the record, does the internal long test stop at the first > unrecoverable read error? Meaning, if there are multiple bad blocks, > just clearing one doesn't do the job, since the next one will appear on > the next scan. In this case, the internal long test was 80% complete > when it emitted the LBA bad block. > > I'm working through a procedure to follow the next time this happens. > Takes a while -- days, in fact, on a 200 GB drive. > > -- Roy Zider > > > ----- Original Message ----- > From: "Christian Franke" <Chr...@t-...> > To: "BitBucket" <fil...@gm...> > Cc: <sma...@li...> > Sent: Tuesday, September 29, 2009 3:11 > Subject: Re: [smartmontools-support] Howto Bad Block in Windows > > > BitBucket wrote: >> OK, got my first bad block/unreadable sector error on a hard disk >> drive. The Bad block HOWTO for smartmontools" at >> http://smartmontools.sourceforge.net/badblockhowto.html has very >> detailed instructions for what to do next -- under Linux. I've >> searched in vain for an reference to doing the same thing under >> Windows (Server 2003), though it is on 80?% of the machines today. >> >> Any pointers to help would be appreciated. >> > > The old MS tool nfi.exe can be used to determine the file affected by a > bad block. This useful tool is (carefully hidden :-) in the OEM Support > Tools for W2K: > http://support.microsoft.com/kb/253066/en-us > It still works on XP and 2003. > > Example: Find volume and file for physical sector (=LBA) 87000000 on > first disk: > > [X:\] nfi \device\harddisk0\dr0 87000000 > > ***Physical sector 87000000 (0x52f83c0) is in file number 181799 on > drive C. > \WINDOWS\Installer\1259885.msp > $STANDARD_INFORMATION (resident) > $FILE_NAME (resident) > $DATA (nonresident) > physical sectors 86995532-87000499 (0x52f724c-0x52f85b3) > > A NG article with further info: > http://groups.google.com/group/microsoft.public.win2000.file_system/browse_thread/thread/7cd6bbd5fade6590/ > > >> (Great tool) >> > > Thanks :-) > > Cheers, > Christian |
From: BitBucket <fil...@gm...> - 2009-09-30 23:59:53
|
Joe and Christian: Thank you both for your comments. I've about got the problem drive back into service, and am writing up some notes for a protocol to follow the next time this happens. But in the course of writing that protocol, which while not as complicated and as detailed as that in the smartmontools reference that prompted this thread in the first place ( "The Bad block HOWTO for smartmontools" at http://smartmontools.sourceforge.net/badblockhowto.html), it's still more complicated than perhaps it needs to be, since I did a bit of disk exploration with nfi.exe and WinHex in the course of examining the error. Here's a simpler protocol to follow when smartd throws an unreadable ecc error: 1. Scan the full drive with CDCheck, checking all readable files (and hashes if any) 2. Note the files that have read errors -- these cover all the bad blocks if more than just one 4. Rename the files with pre/post pend string to identify as bad, but don't delete (prevents reallocation) 3. Replace the files with good files (if you have them -- if not, maybe you'll get lucky with chkdsk) 4. Run chkdsk /r on the drive. This (supposedly) will identify bad sectors in files (stage 4) and free space (stage 5), if there are any to be found at this point, and attempt to recover the data. Using CDCheck at 1. covers the problem of multiple bad sector errors not being picked up since smartd will stop its short/long tests at the first error it encounters. It also skips having to connect the LBA physical sector to a file using nfi.exe, a pita if there ever was one due to the misinformation about device designation. Using chkdsk /r at 4 is a guess on my part, since the "pending" bad sector had already been reallocated by my use of WinHex to explore the area, so unless there were more errors chkdsk /r was not going to find anything -- which it didn't. Even doing this, the drive will be out of service for at least a day or more. CDCheck on my 200GB drive (with 1.1 million files) took about 18 hours to scan the drive. CHKDSK took about 6 hours to do its five-phase scan. Clearly these times will be lower for drives that aren't 95% full like this one was. This protocol means you don't have to remove the drive from service or back it up first or any other of that bothersome belt-and-suspenders busywork we all do (don't we?) because it's best practice. This is clearly the optimistic protocol, which will probably only be used by people who still don't fasten their seat belts. But it should work OK in a tight situation. Hope these comments are helpful. Thanks again for a great little tool. -- Roy Zider ----- Original Message ----- From: "Joe Krahn" <kr...@ni...> To: "BitBucket" <fil...@gm...> Cc: "Christian Franke" <Chr...@t-...>; <sma...@li...> Sent: Tuesday, September 29, 2009 12:40 Subject: Re: [smartmontools-support] Howto Bad Block in Windows With modern drives, bad blocks are handled internally. The block will stay stuck as unreadable until you overwrite it with new data. Then, the driver will internally mark it as bad, and allocate a spare block to take it's place. I don't know how Windows handles blocks, but it may be sufficient to delete the bad file. Ideally, the next access to the bad block will be a write operation. Drive self-tests will stop at a single error. When that happens, it is best to do a read of the entire disk, flagging blocks that give I/O errors. With drives modern drives getting huge capacities, I expect that an occasional lost block will be more common. Hopefully, the OS'es will get better at handling damaged blocks. Joe Krahn BitBucket wrote: > Christian: > > Did find nfi.exe in my bag of tricks, after rummaging around on my > systems. It's only one step, though, since the rest of the story is > what to do with the sector/cluster/block whole drive once you've found > it. (Windows tools and procedures in this case) > > For the record, does the internal long test stop at the first > unrecoverable read error? Meaning, if there are multiple bad blocks, > just clearing one doesn't do the job, since the next one will appear > on > the next scan. In this case, the internal long test was 80% complete > when it emitted the LBA bad block. > > I'm working through a procedure to follow the next time this happens. > Takes a while -- days, in fact, on a 200 GB drive. > > -- Roy Zider > > > ----- Original Message ----- > From: "Christian Franke" <Chr...@t-...> > To: "BitBucket" <fil...@gm...> > Cc: <sma...@li...> > Sent: Tuesday, September 29, 2009 3:11 > Subject: Re: [smartmontools-support] Howto Bad Block in Windows > > > BitBucket wrote: >> OK, got my first bad block/unreadable sector error on a hard disk >> drive. The Bad block HOWTO for smartmontools" at >> http://smartmontools.sourceforge.net/badblockhowto.html has very >> detailed instructions for what to do next -- under Linux. I've >> searched in vain for an reference to doing the same thing under >> Windows (Server 2003), though it is on 80?% of the machines today. >> >> Any pointers to help would be appreciated. >> > > The old MS tool nfi.exe can be used to determine the file affected by > a > bad block. This useful tool is (carefully hidden :-) in the OEM > Support > Tools for W2K: > http://support.microsoft.com/kb/253066/en-us > It still works on XP and 2003. > > Example: Find volume and file for physical sector (=LBA) 87000000 on > first disk: > > [X:\] nfi \device\harddisk0\dr0 87000000 > > ***Physical sector 87000000 (0x52f83c0) is in file number 181799 on > drive C. > \WINDOWS\Installer\1259885.msp > $STANDARD_INFORMATION (resident) > $FILE_NAME (resident) > $DATA (nonresident) > physical sectors 86995532-87000499 (0x52f724c-0x52f85b3) > > A NG article with further info: > http://groups.google.com/group/microsoft.public.win2000.file_system/browse_thread/thread/7cd6bbd5fade6590/ > > >> (Great tool) >> > > Thanks :-) > > Cheers, > Christian |