dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
23
share rss forum feed


neonhomer
KK4BFN
Premium
join:2004-01-27
Edgewater, FL
Reviews:
·Bright House
reply to koitsu

Re: [hard drive] Cloned drive... now hanging issues

Old Drive - Seagate ST9160314AS
New Drive - Toshiba MK1676GSX

OS: Windows XP Pro SP3

Cloning tool :Macrium Reflect

For the record, even though I did run Spinrite on the drive, it didn't find any errors that needed to be corrected. It was more of a check to make sure the drive would be healthy enough for the transfer.

Also... I stand corrected on the system. It is a Dell Latitude E6510.
--
"F is for Fire that burns down the whole town...
U is for Uranium...... Bombs...
N is for NO SURVIVORS!!!!!" Sheldon Plankton

Keep Calm and Carry On


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
Thanks for the information.

The reason I wanted to know the drive models has to do with sector size.

The Seagate ST9160314AS and Toshiba MK1676GSX both appear to be physical 512-byte sector drives. I can't be 100% certain with the Toshiba (I can't find anyone else online using that model of drive who has run smartctl against it), but their specification PDF does say 512 bytes (vs. "4096" or "AF 512e" which would indicate a 4096-byte physical sector drive). I wish I could get confirmation.

The first thing that came to mind when you said the issue correlated with drive access was proper partition alignment for 4096-byte sector drives. This is prevalent to Windows XP, which does not align its partitions to optimal byte boundaries (Windows Vista and Windows 7 does). The result is a system which tends to stall or stutter when writing, while not so much while reading.

The next topic, since n_w95482 See Profile has touched on it, is the need for you to run CHKDSK /F C: on your drive drive. Please do this. You'll be told since the volume is in use it cannot fix problems, and "would you like to do this during the next reboot?" Say Yes, and then immediately shut down/reboot Windows.

Since the old drive is gone and you can't show me SMART attributes/statistics for it (this really would have helped me a lot), I'm going to have to assume the drive had both remapped LBAs as well as pending/"suspect" LBAs which could not be read.

The problem with remapped LBAs is that when a remapping occurs, the data stored within that sector is lost, because remapping only occurs when a write to an LBA is performed.

Technical explanation of how this works is below:


LBA 12345 begins to have some problems (drive finds it has to be continually re-read to work, or sometimes cannot be read at all). The drive internally marks LBA 12345 as "suspect", which means the physical sector (12345) cannot be read by anything (no tool can work around this, including Spinrite. Do not believe the snake oil). You would see this as I/O errors when attempting to read data/files.

The data within that physical sector (512 bytes worth) is now lost and LBA 12345 will be unreadable until a write is issues to that LBA (possibly due to formatting the system, possibly due to deleting the file, etc.). Once a write is issued, the drive internally "re-analyses" the sector to see if it's actually bad or not.

If the sector is deemed OK, the data you wrote to that LBA is written to the sector and life goes on (but naturally the previous 512 bytes of data are now overwritten, thus lost).

If the sector is deemed bad, then the drive internally points LBA 12345 at a new physical sector taken from a spare/unused pool (say, sector 3849992383934). From this point forward every time you read/write to LBA 12345, it will actually be accessing sector 3849992383934, rather than sector 12345. The data you wrote to LBA 12345 is written to sector 3849992383934 and life goes on.


So your next question will be: okay, so how do I find out what files may have been damaged? Won't CHKDSK find that?

The answer is no.

Had you run CHKDSK /R C: on the old drive (note I said /R which is different than /F above), if it encountered an unreadable ("suspect") LBA, it may have been able to tell you what files were unreadable (maybe). However, regardless of this fact, CHKDSK has absolutely no way to determine if LBA remapping has occurred (remember: those 512 bytes may be different) -- you would need what's called a checksumming filesystem to do this, which FAT and NTFS are not.

Since you've cloned the old drive to a new drive, that means (ideally/hopefully of course :-) ) the new drive has no sector anomalies. Which means, there are almost certainly files throughout the drive which have had LBAs remapped transparently "underneathe" them (for lack of better term) and may now contain bogus/busted data.

The errors you see in your above output are not indicating "problems with file integrity", but with inconsistencies within the allocation table/data structures for the filesystem. This is different than the actual contents of a file itself.

So what's your choice here? Well, the only choice in dealing with remapped LBAs is to restore the file which you know to be good/have the proper data in it. But how do you figure out what files those are? Yeah, that's the problem -- without a checksumming filesystem you can't. Your only choice is to format the drive (a quick format is fine) and reinstall the entire OS + every application + etc.. Sad but true. :-(

It would really, really help if I could have seen a screen shot or something of the old drive and what indicated it was busted and should be replaced... If you have this, I would love it see it. I'm looking for SMART attributes specifically.

--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


neonhomer
KK4BFN
Premium
join:2004-01-27
Edgewater, FL
Reviews:
·Bright House
The only error the drive had was a "C5 - Current Pending Sector" with a count of 2 and "C6 - Uncorrectable Sector" with a count of 1. I had a couple of screenshots that I used when sending to Dell, but I can't find the damn things.

Bad thing was the old drive went out already. Ugh...

I'm trying to avoid a wipe and reload.

As for the AF... I ran Toshiba's Align tool (Paragon) on the drive, and it says that it does not need (or support) it.

Oh... I ran chkdsk on the drive as well... It supposedly fixed the issues it found. I'm waiting to see if the problem pops up again. So far, I haven't used my system enough today to see if it is doing again.

--
"F is for Fire that burns down the whole town...
U is for Uranium...... Bombs...
N is for NO SURVIVORS!!!!!" Sheldon Plankton

Keep Calm and Carry On


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
That information helps a lot -- thank you very very much!

Attribute 0xC5 is what I referred to as "suspect" or non-readable LBAs. That means you had (actively) 2 LBAs which couldn't be read. So Spinrite telling you there were no errors is hilarious -- there were absolutely 2 LBAs (1024 bytes total) it couldn't read. These LBAs have not been remapped yet -- they're "pending" to be analysed by the drive, which as I described, is only done when a write is issued. Macrium should have told you the same. How a program handles an I/O (read) error is up to its code -- most tend to fill the unreadable portion with zeros. There is the possibility that the firmware on the drive is buggy (have seen this many times) and that the number (2) should actually be zero.

Attribute 0xC6 is a counter that tracks the number of sectors which when reading or writing to, failed. For reading, this means the ECC portion of the sector couldn't be read or couldn't be used to auto-correct the data. For writing this means a sector which is just downright screwed -- as in dust on the platter, a magnetic substrate anomaly (surface damage), or something along those lines.

Anyway, my point is (with attribute 0xC5) that there's a chance the lost/unreadable 1024 bytes of data could have resided in something like a device driver file, or something "key" to the OS itself thus causing you the problems you're having now. The only solution is a checksumming filesystem, or since there isn't one for XP, reinstallation. :-( I know, it sucks. This problem affects most OSes though, barring those with checksumming filesystems.

If you're at all concerned about the health of your current drive (the Toshiba), please install HD Tune Pro (trial version is fine; please do not use the Free version) and provide me a screenshot of the Health tab and I can tell you if there's anything anomalous there. You may need to resize the window to make sure all the attributes are shown.

Sorry I can't be of more help.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.