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
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
which is different than
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.