Handling Damaged Files

[Spinman]

Running 2.5.0.2968 beta on WHS2011

 

Just thinking outloud...

[i know it has been said before that the scanner program is designed not to write to the hard disk]

 

 

I just had a disk develop problems - currently 4,390 bad sectors on a 3TB advanced format drive per Stablebit Scanner. [Why does HD Sentinel v4.50 only report 592 weak sectors?]  The drive is marked "Damaged", and the drive pool balancer started to move files off of the drive (until I turned it off).

 

I ran a file scan, and only one file was reported as being damaged. My only automoated option appears to be to try to recover the file.

 

1) Why not add an option to permit me to delete the file from the results screen?  Instead, I had to manually track down the file to delete it via Windows Explorer.

 

After I deleted the file, I ran another file scan and it reported no damaged files.

 

I copied over the file from my backup offline storage.  Almost immediately, HD Sentinel reported another bad sector on the drive. I started another Stablebit Scanner file scan, and the same file was reported as damaged. So apparently, the location where that file is being stored is still unstable.

 

2) Why not add an option to permit me to deep scan all of the sectors of a damaged file to see if additional damaged surface area can be found and marked inactive? I don't want to scan the entire 3TB drive again, if only a small area is damaged. 

 

To prevent the problem from replicating again when I replaced the damaged file with my backup copy, I left it on the disk, rename it to "Damaged File.xxx", and reloated it to the root directory outside the pool.  I then copied the backup file to the drive - this time to a different location, as the damaged area is still occupied by the "Damaged File.xxx".

 

3) Why not add an option to permit me to rename the file from the results screen? Instead, I had to manually track down the file to rename it via Windows Explorer.

 

 

I am now paranoid about the stability of this drive, and am concerned about further deteriation over time.   Waiting to see if I should RMA it...

 

4) Why not add an option to rescan "damaged drives" on a different time schedule vs. the default 30 day cycle.  I might like to scan this drive every 14 days to ensure that there is no additional performance deteriation.

 

 

5) I noticed that were were good sectors mixed in with bad sectors.  Why not add an option to block off and mark all sectors as bad beginning with xxxxx and ending with xxxxx - that way you are not trying to store data in a questionable area.

 

 

Just some thoughts...

 

 

 

 

 

 

[Christopher (Drashna)]

1. We could probably put a "delete affected file" option here. Another suggestion we've had recently is to make Scanner "DrivePool" aware, and grab the duplicate file and basically write over it. It's an option. And I've passed it onto Alex.

   However, you don't need to delete the file to fix the bad sector. In fact, deleting it doesn't fix it at all. Specifically, any time you write to affected portion of the disk, the disk itself is supposed "fix" the issue by re-allocating it (hence the "Reallocated sector count" in SMART).

   And you can force the disk to identify the issue and fix it by running a "chkdsk /r" pass on the disk. The "/r" flag is specifically to identify and recover bad sectors. 

2. The reason we don't have an option for this is that Scanner isn't really "file aware" when it's doing the surface scan. It's checking sector by sector for sections that it cannot read.

   However, when you run the file recovery, it reads each and every sector of the affected files. It then attempts a number of "head placement strategies" to see if we can read the damaged sections and actually fully recover the affected files. 

   So basically, the file recovery process is doing this already. We just don't "clean up" the damage sections on the disk.

3. Seen number #1

   But if you are seeing a growing number of damaged sectors, then ABSOLUTELY RMA IT. 

   The reason is that under normal circumstances, you should never see damaged sectors. The disks internal error correction and SMART should identify these issues and fix them silently, before any "harm" is done to the disks. When you see damaged sectors, it means that the disk has failed to do this.  

   While this may happen from time to time, if you're seeing this happen a lot, then there is likely something wrong with the disk.

4. A custom disk threshold or a "rescan recently damaged disk more often" option may be a good idea.
5. Again, NTFS and your disk are supposed to be doing this automatically. Once a damaged sector has been written to, which happens under normal usage (or when forced, such as a format, or chkdsk /r), the disk sees the damaged sector, and reallocates it to a spare good one. And it then should increase the "Reallocated sector count" value on the disk, I believe. But again, this should be happening automatically. 

 

The thing is, all this happens normally. Scanner is just making it obvious. That, and I believe that chkdsk is more concerned with reallocating the data, than it is with recovering it. Specifically, it just tries to read the data, and if it fails, it reallocates it. And at this point, you lose the data. As I said, we use a bunch of head placement strategies to try and read the data. I believe there are 20 "profiles" we use while attempting to read the affected data. But it only needs to read once. Once that's done, we save the recovered file. However, we don't clean up the disk, in case we do fail, or the recovered data is corrupted. That way, if you need to, you can run data recovery tools and intentionally save the file that way.

 

 

I'm not 100% certain about all of this, but this topic has come up a lot lately, and I've talked with Alex extensively about this. Because this is a very complicated and sensitive topic. And a very, very important one.