Should I Be Concerned About Overuse of Same Sectors?

[sburtchin]

I saw this in another thread and it has me rethinking everything about where I keep my paging file, temporary files, and personal data.Seems the constant change/rewriting of data on the HDD platter causes clusters to fail.
On the previous [almost new 80 GB Maxtor HDD] I found 80 faulty clusters on D: where the personal data was held, and now it's happening again on the replacement almost new 80 GB Maxtor HDD.Of course, ALL of my hard drives are Maxtor too. I have a partition dedicated to just the paging file, and another dedicated to just the temporary files. My personal data is on a big NTFS partition with lots of other stuff.

Do I need to periodically move the paging file and temporary files to other areas of the disk to avoid problems like this?

[classicsoftware]

No. I think Sylvander is way off base...

[sburtchin]

Thanks for the heads up!

No idea what's causing his problem, but my HD passes the mfgr's health test with flying colors after a few years similar (ab)use.

[Sylvander]

"I think Sylvander is way off base..."
I have no knowledge of a theoretical reason why this should be so...
Just reporting my suspicions/conclusions/fears from what I am seeing.

I found 80 faulty clusters on my 1st 80 GB Maxtor HDD, and all of these were on the small [1 GB] D: partition where I hold my personal data that changes most.

I took those clusters out of use and swapped the HDD out to an external USB HDD enclosure and replaced it internally with a new 80 GB Maxtor HDD...
And now I'm once again finding lots [hundreds or thousands] of lost file fragments on the small 1 GB D: partition, and suspect that if/when I scan for faulty clusters, there will be some found [must do that soon]. :(

"it has me rethinking"
Same here. :confused:

[Erik]

Maybe the problem isn't with the frequent reads and writes but with the brand of HD. I have never had a problem like this on my drives.

Also keep in mind that a HD is a mechanical device and has a MTBF, maybe you just got unlucky and got some on the short end of the spectrum.

[Sylvander]

I just scanned the C: and D: partitions [cancelled part way through E: 'cause it takes to long and I don't have the time right now].

There were NO faulty clusters found. :)
So I guess my fears were unfounded.

There were yet more [a few] faults in the file system though [fixed those]. How come? :( :confused:
Almost every time I scan there is at least a few faults needing fixed; I'd expect it to come up clean nearly every time.

One longstanding unfixed fault is with an "invalid long filename" on C:
It says to run Scandisk within Windows, but I'm running Win2000Pro, and the only Scandisk is a DOS version that cannot run within Windows, and Chkdsk doesn't fix the problem.

[mjc]

One longstanding unfixed fault is with an "invalid long filename" on C:
It says to run Scandisk within Windows, but I'm running Win2000Pro, and the only Scandisk is a DOS version that cannot run within Windows, and Chkdsk doesn't fix the problem.

THAT is part of the problem...DOS Scandisk and Win2K do not agree on long file names...the limits for number of characters, allowed characters and several other things are different in 2k. If using Chkdsk in 2K doesn't say there are any errors, then you are fine.

[kiosk]

The drive platters are normally uniform in quality. You're seeing more read/write errors in system/OS areas simply because they are accessed much more often than the "data" area of the drive. Thus the higher statistical probability of encountering sloppily written data chunks that are not compromised, but only when ECC (error correction) is applied. All disk drives do this, you'd freak out if you unleashed Spinrite 6 on any of your drives - take notice at just how many times ECC has to be applied to reassemble the badly written data.
Some disk maintenance utilities panic when they encounter ECC and immediately mark the sector as "bad". Scandisk is notorious for panicking.

Basically, there are two ways you can write a sector of data to the drive:
1) Write 512 bytes of data, wait until the platter turns, read those 512 bytes, compare with 512 bytes in memory, if some bits don't match, rewrite and repeat until the data on the disk matches the data in memory. If the data matches after the first write, move on to the next sector immediately.
This is a very slow, but reliable way of writing. You can instruct some (maxtor) drives through firmware updates to operate in this mode, but it brings a 60-70% speed penalty when writing.

2) Write 512 bytes of data, and a 64 bytes checksum (for a 576 byte "hard" sector). No error checking is done after writing. When reading, the disk controller runs the 512 byte data sector through 64 byte checksum and if it adds up, great, the data is successfully retrieved. If it doesn't, some bits in the data sectors are obviously wrong; disk controller software can use the 64 byte checksum to internally detect "wrong" bits (up to a certain amount of them) and reconstruct the sector - this is called ECC and it sometimes launches Scandisk into panic, especially if ECC has to correct more than one "wrong" bit in the sector. If too many bits are uncertain, ECC won't be able to correct it and you'll get a dreaded "Data error reading drive x:" :)

[Sylvander]

"If using Chkdsk in 2K doesn't say there are any errors, then you are fine."
Aaahh...!
But Chkdsk agrees that this problem exists, but fails to fix it just like Scandisk.

Good info kiosk! :)

I assumed that MS Scandisk writes data to the platter, then retrieves it and if it doesn't match the data written it would repeat a couple of times and if it is consistently wrong it marks the cluster as bad.

Assumption wrong?

[mjc]

Now the question is...are the files that the LFN problems exists for accessible?

If they are you may want to either change their names (manually) or do something like shorten the path or even just turn off/ignore LFN errors, they aren't that important if you aren't regularly working with those specific files in true DOS. Even Win98 has better long file name support than DOS (and everything after is better still...Linux, it just doesn't matter, at all).

[kiosk]

I assumed that MS Scandisk writes data to the platter, then retrieves it and if it doesn't match the data written it would repeat a couple of times and if it is consistently wrong it marks the cluster as bad.

Assumption wrong?

Well, Steve Gibson's Spinrite 6 does that; it reads the sector, writes random patterns to it to ensure that every bit can be properly flip-flopped from 0 to 1 and back, then rewrites the sector with original data, compares it with the sector in memory; if it's identical or ECC correctible, spinrite assumes OK, if ECC fails, then the sector is physically defective and marked bad.

MS Scandisk is lazy, it only reads the disk and checks for uncorrectable ECC errors in sectors but doesn't do any writing, which is a shame, since a great deal of "hard" errors can be detected by writing random 0-1 patterns over a single sector, and many "hard" errors can slip through when no writing is done. Worse yet, ECC sometimes doesn't add up due to a variety of reasons, such as very sloppy writing, wobbly drive bay or bad connectors, bad power supply, power brownout, etc. Scandisk sees the ECC failure, goes into panic mode, automatically assuming that the sector is physically defective and marks it as BAD.
I once had a rash of bad sectors appear randomly on an immaculate 8.4 GB seagate. Scandisk was not pleased, and wisely advised me to "have a qualified hardvare technician inspect the drive" or whatever. The problem was eventually traced back to a dying PSU. After I installed a new PSU and did a DOS format with /c /u options, every single scandisk-marked bad sector disappeared, never to be found again. :rolleyes:

Most "serious" disk maintenance programs (CPS Diskfix from early 90's comes to mind) do pattern writing by default. MS Scandisk does not. Why am I not surprised? :rolleyes:

[sburtchin]

So I should avoid use of SCANDISK alltogether and use Spinrite 6 instead to avoid marking good sectors as bad?

[kiosk]

So I should avoid use of SCANDISK alltogether and use Spinrite 6 instead to avoid marking good sectors as bad?

Yes. Scandisk does a pretty bad job; panics at the smallest ECC errors and lets big ones slide by. The fact that Spinrite 6 has a "restore good sectors" function is not a coincidence.

Scandisk should only be used for repairing FAT-related craziness, such as lost clusters and crosslinked files.

[Sylvander]

It seems all those lost file fragments on D: were being caused by [I guess] a mismatch between programs on C: and their data files on D: due to restoring images of C: and D: made at different times.

i.e I make an image of D: and then the matching programs on C: are auto-updated online, and then I make an image of C: and then restore both of those.
After that I boot into Windows, everything has gone haywire, and then when scanning with MS Scandisk there are THOUSANDS of lost file/folder fragments.

If I restore a matched pair [C: and D: made at the same time], then boot into Windows, everything works fine, and there are no lost fragments when I then scan with MS Scandisk.