Chkdsk - X Number Kilobytes in Bad Sectors

There are two types of disk errors one is file coruption which isn't a hardware fault just Windows getting files mixed up and fixed by chkdsk or format. The second is hardware failure which is what you have the actual disk has a fault on some parts. By default any bad sector is remapped to engineering tracks and you don't see them only when that's full do you see errors so it means there are lots of errors. They can't be repaired and will get worse and the disk will fail. You need to replace the disk and do a clean install. On no account try cloning the drive as that will copy bad sectors to a new drive

samuria: Thanks for your response. Not to be contrary, but I question the need for an HD Replacement. That seems (number posts I've read) to be the stock answer without any facts supporting the statement -- replace HD".
AFAIK, a lot of hard disks are shipped with bad sectors. That's how the manufacturer down sizes drives -- i.e. if the platter was manufacturered for a 1TB drive, and has X bad sectors, they call it a 750 GB, or 500 GD, or whatever and sell it as a smaller drive. I'm also of the opinion -- no real basis for my opinion -- that if the File System identifies bad sectors then those sectors should be marked as unavailable, but that in and of itself -IMO - doesn't mean the drive is bad. Most drives are rated with a MBTF of ~ 50,000 hours, and I'm sure the manufacturer monitors this pretty closely to see there is NOT much variance from that figure. I did find this ( CHKDSK HDTUNE show bad sectors, but no SMART reallocation events) FWIW:

You're seeing two (at least) differnt things at work.

The "bad sectors" are marked as such in the file system, for reasons lost to time. Possibly there was a transient seek or recoverable read which timed out causing windows to report an i/o error. In the old days (before they loaded tons of software in the drive controller and started LBA) the only way to track potentially bad sectors was for the file system to mark them as such in the file system disk allocation tables.

Then came IDE and LBA, where the drive automagically did bad sector tracking and tracked them inside the drive and did automatic bad sector relocation/reallocation. The idea was the the drive would always appear "perfect" to the attached computer, so the OS could stop worrying about bad sectors. (The OS didn't, thus "bad cluster" marking is still going on in the file system. Of course if the drive lived up to it's claim of always appearing "perfect", the file system would never mark any space as bad/unusable... )

Finally SMART (which is dumb) comes in. The drive is supposed to track statistics and warn when the numbers indicate impending failure. However, what manufacturer is going to confess that their drive is going flakey? Instead, the wait until the last possible moment before sending the SMART "immenent death" message. I've had drives last only 90 minutes from first SMART warning to total failure!

And while the drive is keeping stats, they fudge and clean. Somehow the "worst experienced" number will slowly increase, after a long period of no errors, back up to near the original "never had a problem" values, thus wiping the memory of any problems encountered.

I've seen drives that have two levels of sector reallocation (alternate sector on the same track, and full track reallocation) not bother to count (or at least report in the defined SMART number bucket) the sector reallocs; just the track reallocs. These drives also reported nearly perfect SMART numbers, including no reallocations, until just before the bitter end.

In short, the manufactures will do anything to make their drive SMART data look as good as possible for as long as possible, which defeats the whole goal of failure prediction.

So what you probably saw was a glitch in an average drive which isn't going to fail any sooner than most of its production run siblings, resulting in the file system creating a "bad area" record for an area that the drive would say is perfectly usable. I'd wager a file system true low level chkdsk type full-read test would return the failed area to use.

• Marked as answer by Jeffery Smith Monday, February 08, 2010 9:19 PM

I don't know who Jeffery Smith is, but answer seems logical. Would be nice if some authority -- Chen, Gibson, etc. would detail what's going on and what can be done, if anything.

My recomendation with over 30 years in IT is replace the drive at the end of the day its your data you do a risk assesment on your data

The drive will remap bad sectors during a write operation. This is possible because the accurate contents of the sector is known. But during a read operation there isn't much that can be done if an error is detected. Remapping the sector would eliminate any possibility of recovering it's data. The drive does keep track of the sector and will remap it if there is a later write to the sector or if a read succeeds. You have no assurance that either will occur.

I would replace the drive.

The 12K equating to 4 clusters is somewhat misleading. By default chkdsk does not check file contents or sectors not yet assigned to files. These could contain many more bad sectors. And drive errors tend to get worse with time and you have no way of knowing how much. As always be very sure you have a backup of all important files. This is always important but particularly so with a questionable drive.

SMART and other tests will reveal detected problems but the lack of errors does not necessarily mean all is well. The "check engine light" in your car will warn you of problems but the lack of a warning does not mean all is well.

Thanks both for taking your time to respond.

Maybe I'm reading to much between the lines.
One question is why Chkdsk even shows bytes in bad sectors. One would think if:
1) Chkdsk can recover the data, it would either move it to another sector and mark the bad sector as bad (so not to reuse it) - OR
2) if can only recover part of the data, create a file in the "found000" directory with this partial data
- OR
3) if data not recoverable, just mark the sector as bad and not use it.

Checking further will post back.

Chkdsk showed bad sectors because it was unable to read them. Whatever file they were a part of is corrupt and chkdsk can't fix the problem. This being the case the best thing to do is leave things as they are. The problem may be temporary and at some later time the sectors may be successfully read. The drive would then be able to replace them with spares and no data would be lost. If the sectors were remapped when they problem first appeared there would be no hope of recovery and the data would be permanently lost. If the sectors can not be read we are no worse off.

Be aware that bad sector remapping is done internally by the drive and chkdsk has no control over it. What chkdsk did was to make the drive aware of the bad sectors.

LMiller7: Makes sense, thanks for followup.

FWIW and prior to your post.
Went ahead and did my normal clone backup, then ran Chkdsk on clone.
Same 12KB shows, so IMO reflects a function of NTFS not HD failure issue.
One would think (??), that if the file could be placed in the
same or new sector on the cloned drive, the issue would disappear since the
likelyhood that that same sector on the clone would be bad.
Looking into some Linux tools - appear available - to see what other info about the drive / files, if any, I can gather.

As I explained in my post never ever clone a drive with bad sectors as it writes them to new drive which is almost impossible to recover spinwrite may do it. A clone is an exact copy of the drive bad sectors and all

samuria:

I guess I can reload the OS on the new drive from CD, but
If you don't mind my asking, what do you suggest -- easiest way - to:
1) Keep from having to reload all software from CD.
AND
2) Copy all "data" folders / files to the new drive