What was in bad NTFS sectors?

[IanWorthington]

Had a 3TB NTFS drive go bad on me a few days ago. I've ddrescued it to an image and determined that a single 4k sector (8x512b ntfs psuedo sectors) is unreadable.

I would like to try and determine what is damaged so I know what I need to restore from backup after reimaging it. A CHKDSK on the disk seems to suggest the error /may/ affect an ntfs index structure, buts its far from certain.

Questions:

1. Could the chkdsk results suggest that I've lost a whole subtree of files or does ntfs maintain redundant pointers to protect against this?

2. Is there anyway of determining what those damaged sectors actually contained? I've done some google searches but haven't yet found anything that can chase the ntfs chains and tell me what lies at that address.

 

[mikeymikec]

There are two MFTs normally in an NTFS file system, so both would have to be damaged in the same place to lose file system structure information. Losing a specific subtree is pretty unlikely unless the disk is properly buggered and loads of other areas are unreadable, or at least, the disk is having problems reading the platter(s).

The chkdsk results in the event viewer > application log > wininit entry will tell you where bad sectors have been found, and chkdsk /r will try and recover data from those sectors. Normally the chkdsk results tell me that a particular file was affected by bad sectors.

 

[IanWorthington]

There are two MFTs normally in an NTFS file system, so both would have to be damaged in the same place to lose file system structure information. Losing a specific subtree is pretty unlikely unless the disk is properly buggered and loads of other areas are unreadable, or at least, the disk is having problems reading the platter(s).

The chkdsk results in the event viewer > application log > wininit entry will tell you where bad sectors have been found, and chkdsk /r will try and recover data from those sectors. Normally the chkdsk results tell me that a particular file was affected by bad sectors.

Thanks mikeymikec.

I took a look for winnit (and chkdsk) entries but couldn't find anything. iirc I may have cancelled the winnit run when I saw it start having problems and the manual runs have always ended with a disk disconnect so maybe they don't get logged unless they complete?

So I ran manually again, specifying /x in case it was other activity that was causing the disconnect rather than chkdsk. This appears to be the case, this time the run completed, as below. If I understand the output correctly, it identifies as damaged a directory which in this case is a cifs share used by the router to write stats. I'm assuming this was the cause of the regular disconnects.

Slightly curious why /all/ of the 30+ files in that directory where not orphaned, rather than only 7 of them but that's by the by.

SMART data is showing 8 sectors as current pending and offline uncorrectable. Reallocated sectors is 0. Notwithstanding its low value it fails self check so I'm assuming it's time to ditch this drive?


i

C:\Windows\system32>chkdsk  d: /x
The type of the file system is NTFS.
Volume label is p8-d3.

CHKDSK is verifying files (stage 1 of 3)...
  1110272 file records processed.
File verification completed.
  18814 large file records processed.
  0 bad file records processed.
  0 EA records processed.
  0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
70 percent complete. (1239258 of 1368498 index entries processed)
Correcting error in index $I30 for file 1097560.
Correcting error in index $I30 for file 1097560.
Sorting index $I30 in file 1097560.
  1368498 index entries processed.
Index verification completed.
CHKDSK is scanning unindexed files for reconnect to their original directory.
76 percent complete. (1 of 7 unindexed files scanned)
Recovering orphaned file TOMATO~4.BAK (1243) into directory file 1097560.
Recovering orphaned file tomato_rstats_0016018ee722_2.bak (1243) into directory file 1097560.
Recovering orphaned file TOMATO~1.BAK (1261) into directory file 1097560.
Recovering orphaned file tomato_rstats_0016018ee722_5.bak (1261) into directory file 1097560.
Recovering orphaned file TOMATO~2.BAK (1263) into directory file 1097560.
Recovering orphaned file tomato_rstats_0016018ee722_4.bak (1263) into directory file 1097560.
76 percent complete. (4 of 7 unindexed files scanned)
Recovering orphaned file TOMATO~3.BAK (1289) into directory file 1097560.
Recovering orphaned file tomato_rstats_0016018ee722_3.bak (1289) into directory file 1097560.
Recovering orphaned file TO062B~1.BAK (1307) into directory file 1097560.
Recovering orphaned file tomato_rstats_0016018ee722_1.bak (1307) into directory file 1097560.
Recovering orphaned file TOMATO~1.GZ (467336) into directory file 1097560.
Recovering orphaned file tomato_rstats_0016018ee722.gz (467336) into directory file 1097560.
  7 unindexed files scanned.
Recovering orphaned file WINDOW~1.PCA (1097904) into directory file 1097560.
Recovering orphaned file windows claro trace 2013feb20-1554.pcapng (1097904) into directory file 1097560.
  0 unindexed files recovered.
CHKDSK is verifying security descriptors (stage 3 of 3)...
  1110272 file SDs/SIDs processed.
Security descriptor verification completed.
  129114 data files processed.
CHKDSK is verifying Usn Journal...
  36491704 USN bytes processed.
Usn Journal verification completed.
Adding 1 bad clusters to the Bad Clusters File.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.

   2861458 MB total disk space.
   2528637 MB in 913193 files.
    938088 KB in 129115 indexes.
         4 KB in bad sectors.
   1302455 KB in use by the system.
     65536 KB occupied by the log file.
 338568744 KB available on disk.

      4096 bytes in each allocation unit.
 732533503 total allocation units on disk.
  84642186 allocation units available on disk.

C:\Windows\system32>

 

[mikeymikec]

It depends on how you feel about it. Some people might be inclined to run it until it dies, others don't want to take the risk of it dying at an inconvenient moment.

If you're running chkdsk during a Windows session, normally it gets put in eventvwr > Windows logs > Application log, under the source 'chkdsk' ('wininit' gets used if you run a disk check during Windows startup). If you cancelled the scan mid way then I don't think it records an event.

I normally do chkdsk /f /v /r to ensure that it runs a complete check and doesn't skip any logging information (I've seen conflicting information on the MS site about the /v switch so I keep it in). I think in this case you've got all you need to know though.

The SMART data regarding bad sectors won't ever be in sync with NTFS because they each keep separate data - if one system finds the bad sector, the other probably won't get to find out about it because the sector has already been reallocated.

 

[IanWorthington]

Thanks again.

 

[fzabkar]

Tip: How to determine which file occupies a particular sector:
http://forums.seagate.com/t5/Deskto...h-file-occupies-a-particular-sector/m-p/35567

I believe WinHex (commercial) can also do what you want.

 

[IanWorthington]

Tip: How to determine which file occupies a particular sector:
http://forums.seagate.com/t5/Deskto...h-file-occupies-a-particular-sector/m-p/35567

I believe WinHex (commercial) can also do what you want.

NFI looks real interesting, I'll check it out! Thanks!