Wierd chkdsk issue

[teckytim]

I have a weird problem when I run chkdsk /r on a NTFS partition (win XP
SP2). I get a the message like:

"Windows replaced bad clusters in file 733
of name \FOLDER\FOLDER\FILE.EXT."

It's weird because chkdsk also reports:

"Windows has checked the file system and found no problem."
And "0 KB in bad sectors."

It also doesn't seem to ever fix the problem so I get exactly the
same output if I rerun chkdsk /r.

I thought it was corrupt files. This seemed likely as I restored the
files to another disk from an old backup and got the same chkdsk
behavior. Interestingly chkdsk /f reports no file problems (on either
disk) and the files seem to me perfectly OK. In fact one of the
"bad" files is a TrueImage disk image. It passes TrueImage's
file check and restores correctly.

I ran SpinRite 6 at level 4 and it found nothing wrong with the disk.
(for whatever that's worth)


Any ideas what's going on here?

 

[David A. Flory]

I have a weird problem when I run chkdsk /r on a NTFS partition (win XP
SP2). I get a the message like:

"Windows replaced bad clusters in file 733
of name \FOLDER\FOLDER\FILE.EXT."

It's weird because chkdsk also reports:

"Windows has checked the file system and found no problem."
And "0 KB in bad sectors."

It also doesn't seem to ever fix the problem so I get exactly the
same output if I rerun chkdsk /r.

I thought it was corrupt files. This seemed likely as I restored the
files to another disk from an old backup and got the same chkdsk
behavior. Interestingly chkdsk /f reports no file problems (on either
disk) and the files seem to me perfectly OK. In fact one of the
"bad" files is a TrueImage disk image. It passes TrueImage's
file check and restores correctly.

I ran SpinRite 6 at level 4 and it found nothing wrong with the disk.
(for whatever that's worth)


Any ideas what's going on here?

Interesting problem...

FYI, clusters and sectors aren't the same. A bad sector is a physical
defect on the drive, and with modern drives you really shouldn't have
any. You don't have any, which is good!

Clusters (or allocation units) are defined by the filesystem, and are
usually 4K on NTFS but can be larger. BTW, Chkdsk can report errors
where there aren't any. My guess is it is being fooled by Truimage's
disk image format, and you have nothing to worry about.

Best Regards,

Dave

 

[Rod Speed]

teckytim wrote

Presumably thats just making a distinction between
a problem in the FILE SYSTEM, and a problem with
the bad cluster(s) and is just rather poorly worded.

This is a bit strange, but likely something to do with the next bit.

Which certainly should eliminate the possibility of a real bad cluster.

Yeah, looks like chkdsk is having a brain fart, particularly with the restored image.

Looks like some quirk of chkdsk.

Interesting problem...

It is indeed.

FYI, clusters and sectors aren't the same. A bad sector is a physical
defect on the drive, and with modern drives you really shouldn't have any.

Its more complicated than that. You can have bad sectors until that
sector is overwritten, in which case the drive should reallocate that sector.

You don't have any, which is good!

Clusters (or allocation units) are defined by the filesystem, and are usually 4K on NTFS but can
be larger.

But are multiple sectors and it shouldnt be possible to have
a bad cluster without one of the sectors in it being bad.

BTW, Chkdsk can report errors where there aren't any.

Thats file system errors tho, not bad clusters.

My guess is it is being fooled by Truimage's disk image format,

chkdsk knows nothing about the CONTENTS of a file.

and you have nothing to worry about.

Yes, but not for that reason.

 

[Folkert Rienstra]

Could (as in speculation) mean that the file uses clusters that are also
administrated as being bad (don't know if that's actually possible).
In such case it may try to copy the data in those supposedly bad
clusters to new clusters that are free.
Which of course is completely weird in more than one sense, but hey.

Which is kind of correct if it successfully fixed some.
Unfortunately that is not what we expect it to be.

Again correct if it could successfully read the bad sectors that were
supposedly bad. Again, counter intuitive.

Well, there goes all the speculative theory out the window.

Not likely if it is a physical sector-for-sector image backup.
Filesystem errors are simply copied that way to your backup.

Interesting problem...

FYI, clusters and sectors aren't the same.

A bad sector is a physical defect on the drive,

That was the idea. Unfortunately it just means that
the recorded ECC doesn't match the calculated one.

and with modern drives you really shouldn't have any.

Nonsense, nothing to do with 'modern' drives at all.
Though current and future drives may incorporate strategies to avoid
areas being not read for longer periods, avoiding that sectors go bad
unoticed until it is too late for the drive to reassign them on the fly.
Drives can still abort writes in emergency situations leaving incomple-
tely written sectors which show up as bad sectors due to wrong ECC.
These will not be automagically reassigned on reads.

You don't have any, which is good!

Clusters (or allocation units) are defined by the filesystem,

.... but are comprised of sectors.
Even though it says sectors in the report, it means clusters.
Most likely only one out of every 8 sectors in bad sectors are bad.

and are usually 4K on NTFS but can be larger.

BTW, Chkdsk can report errors where there aren't any.

As is obvious by this example.
Question is, is this one of those instances that are documented.

My guess is it is being fooled by Truimage's
disk image format, and you have nothing to worry about.

Filesystem checking utes usually don't care about file contents.

 

[teckytim]

Interesting problem...

FYI, clusters and sectors aren't the same. A bad sector is a physical
defect on the drive,

FYI I'm trying to determine *which* is the problem.

and with modern drives you really shouldn't have
any.

It would if the drive were failing.

You don't have any, which is good!

Not necessarily. It makes the situation harder to troubleshoot &
understand.

Clusters (or allocation units) are defined by the filesystem, and are
usually 4K on NTFS but can be larger.

NTFS clusters can be as small as 512-byte

BTW, Chkdsk can report errors
where there aren't any.

What do you mean? The verbose cleanup messages from the sloppy
journalizing and reports of errors when chkdsk doesn't have exclusive
access? I don't consider that *errors* although it can be confusing.
This situation is different than those.

My guess is it is being fooled by Truimage's
disk image format,

An interesting theory as the files in question are TrueImage disk
images, DVD ISO images, and Microsoft and VmWare Virtual disks. The
problem is that chkdsk doesn't normally care about file contents. If
fact it sees no problem with most of the other files of those types on
the disk. It also *used* to report these particular files as ok. For
some reason chkdsk /r is now reporting problems with these particular
files even though I did not modify them. And no there are no viri or
malware infections. The system is very strictly controlled and
scanned.

and you have nothing to worry about.

I appreciate the help. But I'm still worried.

Actually the problem is on two separate machines. 1 is a dedicated
server with a win 2000 raid 5 set of Seagate 7200.8 SATA drives. The
other is a Win XP SP2 workstation with a 7200.7 PATA drive. To be a
little more specific the server's RAID set reports "Windows has checked
the file system and found no problem." The PATA drive doesn't (as if
it has actually identified and fixed something). Otherwise the
behoviour is identical.

My suspicion is that the common thread isn't that they are disk
images. Instead that they are very large files. Interestingly a few
years ago I had a workstation with a Seagate Cheetah and a PATA WD. I
bumped into it and a DriveImage disk image *disappeared* from the WD
with chkdsk reporting no problem with the disk or file structure. The
original copy on the Cheetah was fine. I wonder if weird stuff just
sometimes happens sometimes to (P/S)ATA? (please don't flame this
theory. I know it teneous)

 

[Rod Speed]

FYI I'm trying to determine *which* is the problem.


It would if the drive were failing.


Not necessarily. It makes the situation harder to troubleshoot &
understand.


NTFS clusters can be as small as 512-byte


What do you mean? The verbose cleanup messages from the sloppy
journalizing and reports of errors when chkdsk doesn't have exclusive
access? I don't consider that *errors* although it can be confusing.
This situation is different than those.


An interesting theory as the files in question are TrueImage disk
images, DVD ISO images, and Microsoft and VmWare Virtual disks. The
problem is that chkdsk doesn't normally care about file contents. If
fact it sees no problem with most of the other files of those types on
the disk. It also *used* to report these particular files as ok. For
some reason chkdsk /r is now reporting problems with these particular
files even though I did not modify them. And no there are no viri or
malware infections. The system is very strictly controlled and
scanned.


I appreciate the help. But I'm still worried.

Actually the problem is on two separate machines. 1 is a dedicated
server with a win 2000 raid 5 set of Seagate 7200.8 SATA drives. The
other is a Win XP SP2 workstation with a 7200.7 PATA drive. To be a
little more specific the server's RAID set reports "Windows has
checked the file system and found no problem." The PATA drive
doesn't (as if it has actually identified and fixed something).
Otherwise the behoviour is identical.

My suspicion is that the common thread isn't that they are disk
images. Instead that they are very large files. Interestingly a few
years ago I had a workstation with a Seagate Cheetah and a PATA WD. I
bumped into it and a DriveImage disk image *disappeared* from the WD
with chkdsk reporting no problem with the disk or file structure. The
original copy on the Cheetah was fine. I wonder if weird stuff
just sometimes happens sometimes to (P/S)ATA?

No it doesnt, that is a copout.

 

[David A. Flory]

FYI I'm trying to determine *which* is the problem.


It would if the drive were failing.

(that's why I said "shouldn't" --I was making a comparison to early
hard drives that often shipped with bad sectors)

Not necessarily. It makes the situation harder to troubleshoot &
understand.


NTFS clusters can be as small as 512-byte

Okay, okay sorry! Or as large as 64K!

What do you mean? The verbose cleanup messages from the sloppy
journalizing and reports of errors when chkdsk doesn't have exclusive
access? I don't consider that *errors* although it can be confusing.
This situation is different than those.

Okay, thanks for clearing that up. I should have assumed you were
running with exclusive access.

An interesting theory as the files in question are TrueImage disk
images, DVD ISO images, and Microsoft and VmWare Virtual disks. The
problem is that chkdsk doesn't normally care about file contents. If
fact it sees no problem with most of the other files of those types on
the disk. It also *used* to report these particular files as ok. For
some reason chkdsk /r is now reporting problems with these particular
files even though I did not modify them. And no there are no viri or
malware infections. The system is very strictly controlled and
scanned.


I appreciate the help. But I'm still worried.

I didn't mean to minimize your problem. This is what I'm thinking:

1.) You have no bad sectors, but a bad cluster, which is odd, and not
what I would expect if you were having physical drive problems. Also
the drive checks out with SpinRite.

2.) I have no idea how Trueimage works, but I wouldn't be surprised if
it had some flags for recovery purposes. Even if you didn't install a
recovery partition it might still tag image files using some technique
that confuses chkdsk (Maybe Acronis has heard of your problem?)

Actually the problem is on two separate machines. 1 is a dedicated
server with a win 2000 raid 5 set of Seagate 7200.8 SATA drives. The
other is a Win XP SP2 workstation with a 7200.7 PATA drive. To be a
little more specific the server's RAID set reports "Windows has checked
the file system and found no problem." The PATA drive doesn't (as if
it has actually identified and fixed something). Otherwise the
behoviour is identical.

My suspicion is that the common thread isn't that they are disk
images. Instead that they are very large files. Interestingly a few
years ago I had a workstation with a Seagate Cheetah and a PATA WD. I
bumped into it and a DriveImage disk image *disappeared* from the WD
with chkdsk reporting no problem with the disk or file structure. The
original copy on the Cheetah was fine. I wonder if weird stuff just
sometimes happens sometimes to (P/S)ATA? (please don't flame this
theory. I know it teneous)

Were you using FAT? It's hard to imagine how NTFS could "lose" a whole
file...but there are so many bug possibilities in PATA/SATA chipsets,
drivers, (and onboard drive controllers) that I guess almost anything is
possible.

 

[Rod Speed]

(that's why I said "shouldn't" --I was making a comparison to early
hard drives that often shipped with bad sectors)

Okay, okay sorry! Or as large as 64K!
Okay, thanks for clearing that up. I should have assumed you were
running with exclusive access.

I didn't mean to minimize your problem. This is what I'm thinking:

1.) You have no bad sectors, but a bad cluster, which is odd, and not what I would expect if you
were having physical drive problems.

And it shouldnt be possible to REPLACE a
cluster thats bad not due to a bad sector in it.

Also the drive checks out with SpinRite.

Doesnt prove much, its wildly optimistic about bad sectors.

2.) I have no idea how Trueimage works, but I wouldn't be surprised
if it had some flags for recovery purposes. Even if you didn't install a recovery partition it
might still tag image files using some technique that confuses chkdsk (Maybe Acronis has heard of
your problem?)

He said its large files, not just TI files.

 

[teckytim]

No it doesnt, that is a copout.

Perhaps. I just find it strange that I've seen many kinds of wierd
quirks and corruptions on "Personal Storage" and "consumer electronics"
that I haven't seen on quality "Enterprise Storage" and other
"enterprise" gear.

What do you think happened in that case? I'm still at a loss.

 

[teckytim]

David A. Flory wrote:

(edited for brevity)

Okay, thanks for clearing that up. I should have assumed you were
running with exclusive access.

You've got me confused. chkdsk /r & /f imply exclusive access.

I didn't mean to minimize your problem. This is what I'm thinking:

1.) You have no bad sectors, but a bad cluster, which is odd, and not
what I would expect if you were having physical drive problems. Also
the drive checks out with SpinRite.

Which makes me think the drive is *basically* OK but has had at least a
few hard errors in it's lifetime that manifest in this wierd way. Even
though the drives basically work I wonder how much I should trust them.

2.) I have no idea how Trueimage works, but I wouldn't be surprised if
it had some flags for recovery purposes. Even if you didn't install a
recovery partition it might still tag image files using some technique
that confuses chkdsk (Maybe Acronis has heard of your problem?)

I'm not sure I follow. I did a chkdsk /r after the images were first
created. No errors. They sat on the HDD for several months without
being touched. chkdsk /r was run again. Suddenly this problem
appeared and is consistently repeatable. But the same goes for ISO
images and virtual HDD files.

Were you using FAT? It's hard to imagine how NTFS could "lose" a whole
file...but there are so many bug possibilities in PATA/SATA chipsets,
drivers, (and onboard drive controllers) that I guess almost anything is
possible.

Nope. NTFS. The image files were written perfectly & sat on the
machine for some time. I bumped into it and when I checked the
filesystem the whole folder of images were gone (on the ATA drive and
not the mirror on the Cheetah). Totally unrelated to FAT or chipset.
IMHO

 

[David A. Flory]

Hi,


1.) Does the drive manufacturer have diagnostic tools? (i.e. Seatools)
Have you tried that?

2.) I didn't understand what you meant when you said you had the
problem with two machines, yet the Win2000 RAID array didn't give
errors. I understand that you're having this problem on your XP SP2
PATA drive...but what was the problem with the server?

Dave

 

[Rod Speed]

Rod Speed wrote

Perhaps.

No perhaps about it.

I just find it strange that I've seen many kinds of wierd quirks and
corruptions on "Personal Storage" and "consumer electronics" that
I haven't seen on quality "Enterprise Storage" and other "enterprise" gear.

Thats just the competance of the level of user using each class of system.

What do you think happened in that case? I'm still at a loss.

Presumably something deleted it, maybe even DriveImage itself.

 

[Rod Speed]

David A. Flory wrote

You've got me confused. chkdsk /r & /f imply exclusive access.

Which makes me think the drive is *basically* OK but has had at least
a few hard errors in it's lifetime that manifest in this wierd way.
Even though the drives basically work I wonder how much I should
trust them.

Post the Everest SMART report.
http://www.majorgeeks.com/download.php?det=4181

Not even possible.

I'm not sure I follow. I did a chkdsk /r after the images were first
created. No errors. They sat on the HDD for several months without
being touched. chkdsk /r was run again. Suddenly this problem
appeared and is consistently repeatable. But the same goes for ISO
images and virtual HDD files.

Its gotta be some quirk of chkdsk given that
you get the same result with a restored file.

Nope. NTFS.

Even more likely its just a quirk of chkdsk, NTFS is surprisingly complex.

The image files were written perfectly & sat on the machine for some time.
I bumped into it and when I checked the filesystem the whole folder of
images were gone (on the ATA drive and not the mirror on the Cheetah).

Likely something deleted that folder. It isnt that hard to do with some file managers.

Totally unrelated to FAT or chipset. IMHO

Yeah, certainly.

 

[teckytim]

No perhaps about it.


Thats just the competance of the level of user using each class of system.

Now that's a copout.

A hem... It's the *same user* using and comparing *both.*

Presumably something deleted it,

Ya think?

maybe even DriveImage itself.

Not possible.

 

[teckytim]

Hi,


1.) Does the drive manufacturer have diagnostic tools? (i.e. Seatools)
Have you tried that?

Yes. No problems reported. But then it really has to be on it's last
legs to report otherwise.

2.) I didn't understand what you meant when you said you had the
problem with two machines, yet the Win2000 RAID array didn't give
errors. I understand that you're having this problem on your XP SP2
PATA drive...but what was the problem with the server?

It's exactly the same history, same file types in question, and
identical chkdsk /r output on the screen except the 2k OS raid 5 server
reports "Windows has checked the file system and found no problem."
The XP machine doesn't.

I wanted to clarify and explain that the issue isn't isolted. It
exists for me on at least 2 out of 6 disks among these machines. I
tried to just use the XP machine as a troubleshooting example for
simplicity but mixed up that detail. Now explaining the details I
guess makes things more confusing.

 

[teckytim]

Post the Everest SMART report.
http://www.majorgeeks.com/download.php?det=4181

I can't use that right now because I'm on a domain and Everest Home
doesn't like that. This is the output from Active SMART:

============================================================
This report created by Active SMART (http://www.ariolic.com)
============================================================

S.M.A.R.T. status
Date: 15 December 2006 03:31:03

Drive model: ST3200822A
Serial number: 3LJ3BDG2
Capacity: 200.0 GB
Firmware Revision: 3.01
Drive interface: IDE
Drive temperature: 30 °C

--------------------------------------------------------------------------------------------
Attribute Name Threshold Value
Worst Raw value
--------------------------------------------------------------------------------------------
1 (01) Raw Read Error Rate 6 59
51 49274051
3 (03) Spin Up Time 0 96
96 0
4 (04) Start/Stop Count 20 100
100 379
5 (05) Reallocated Sector Count 36 100
100 0
7 (07) Seek Error Rate 30 81
60 135519085
9 (09) Power-on Hours Count 0 96
96 4202
10 (0A) Spin Up Retry Count 97 100
100 0
12 (0C) Power Cycle Count 20 100
100 376
194 (C2) Temperature 0 30
41 30
195 (C3) ECC on the Fly Count 0 59
51 49274051
197 (C5) Current Pending Sector Count 0 100
100 0
198 (C6) Off-line Scan Uncorrect. Sector Count 0 100
100 0
199 (C7) Ultra ATA CRC Error Rate 0 200
200 0
200 (C8) Write Error Count 0 100
253 0
202 (CA) TA Increase Count 0 100
253 0
--------------------------------------------------------------------------------------------

Not even possible.


Its gotta be some quirk of chkdsk given that
you get the same result with a restored file.

Very strange that is would find everything ok a few times and then
suddenly and repeatedly report the same "problem" identically.

Even more likely its just a quirk of chkdsk, NTFS is surprisingly complex.

I assume you aren't commenting on the lost files here.

Likely something deleted that folder. It isnt that hard to do with some file managers.

I didn't get much sleep in those days so I suppose anything is
possible. But a simple delete should have showed up in the recovery
bin. I'd think an aberrant program would have done more damage than
that.

 

[teckytim]

Eww that's ugly formatting. Trying again:

S.M.A.R.T. status
Date: 15 December 2006 03:31:03

Drive model: ST3200822A
Serial number: 3LJ3BDG2
Capacity: 200.0 GB
Firmware Revision: 3.01
Drive interface: IDE
Drive temperature: 30 °C

----------------------------------------------------------------
Attribute Name Threshold Value Worst Raw value
----------------------------------------------------------------
1 (01) Raw Read Error Rate 6 59 51 49274051
3 (03) Spin Up Time 0 96 96 0
4 (04) Start/Stop Count 20 100 100 379
5 (05) Reallocated
Sector Count 36 100 100 0
7 (07) Seek Error Rate 30 81 60 135519085
9 (09) Power-on Hours Count 0 96 96 4202
10 (0A) Spin Up Retry Count 97 100 100 0
12 (0C) Power Cycle Count 20 100 100 376
194 (C2) Temperature 0 30 41 30
195 (C3) ECC on the Fly Count 0 59 51 49274051
197 (C5) Current Pending
Sector Count 0 100 100 0
198 (C6) Off-line Scan
Uncorrect. Sector Count 0 100 100 0
199 (C7) Ultra ATA CRC
Error Rate 0 200 200 0
200 (C8) Write Error Count 0 100 253 0
202 (CA) TA Increase Count 0 100 253 0
------------------------------------------------------------------

 

[teckytim]

Eww that's ugly formatting. Trying again:

S.M.A.R.T. status
Date: 15 December 2006 03:31:03

Drive model: ST3200822A
Serial number: 3LJ3BDG2
Capacity: 200.0 GB
Firmware Revision: 3.01
Drive interface: IDE
Drive temperature: 30 °C

----------------------------------------------------------------
Attribute Name Threshold Value Worst Raw value
----------------------------------------------------------------
1 (01) Raw Read Error Rate 6 59 51 49274051
3 (03) Spin Up Time 0 96 96 0
4 (04) Start/Stop Count 20 100 100 379
5 (05) Reallocated
Sector Count 36 100 100 0
7 (07) Seek Error Rate 30 81 60 135519085
9 (09) Power-on Hours Count 0 96 96 4202
10 (0A) Spin Up Retry Count 97 100 100 0
12 (0C) Power Cycle Count 20 100 100 376
194 (C2) Temperature 0 30 41 30
195 (C3) ECC on the Fly Count 0 59 51 49274051
197 (C5) Current Pending
Sector Count 0 100 100 0
198 (C6) Off-line Scan
Uncorrect. Sector Count 0 100 100 0
199 (C7) Ultra ATA CRC
Error Rate 0 200 200 0
200 (C8) Write Error Count 0 100 253 0
202 (CA) TA Increase Count 0 100 253 0
------------------------------------------------------------------

 

[Rod Speed]

Rod Speed wrote

Now that's a copout.

Nope, its a fact. You see it at every level, most obviously with backups etc.

A hem... It's the *same user* using and comparing *both.*

The problem is between that user's ears.

Ya think?

That is the obvious explanation and completely trivial to prove that.

Not possible.

Then something else did.

 

[Rod Speed]

Rod Speed wrote

I can't use that right now because I'm on a domain and Everest Home
doesn't like that. This is the output from Active SMART:

============================================================
This report created by Active SMART (http://www.ariolic.com)
============================================================

S.M.A.R.T. status
Date: 15 December 2006 03:31:03

Drive model: ST3200822A
Serial number: 3LJ3BDG2
Capacity: 200.0 GB
Firmware Revision: 3.01
Drive interface: IDE
Drive temperature: 30 °C

--------------------------------------------------------------------------------------------
Attribute Name Threshold Value
Worst Raw value
--------------------------------------------------------------------------------------------
1 (01) Raw Read Error Rate 6 59
51 49274051
3 (03) Spin Up Time 0 96
96 0
4 (04) Start/Stop Count 20 100
100 379
5 (05) Reallocated Sector Count 36 100
100 0
7 (07) Seek Error Rate 30 81
60 135519085

That is on the high side, but the rest are fine.

Looks like the drive is fine.

9 (09) Power-on Hours Count 0 96
96 4202
10 (0A) Spin Up Retry Count 97 100
100 0
12 (0C) Power Cycle Count 20 100
100 376
194 (C2) Temperature 0 30
41 30
195 (C3) ECC on the Fly Count 0 59
51 49274051
197 (C5) Current Pending Sector Count 0 100
100 0
198 (C6) Off-line Scan Uncorrect. Sector Count 0 100
100 0
199 (C7) Ultra ATA CRC Error Rate 0 200
200 0
200 (C8) Write Error Count 0 100
253 0
202 (CA) TA Increase Count 0 100
253 0
--------------------------------------------------------------------------------------------

Very strange that is would find everything ok a few times and then
suddenly and repeatedly report the same "problem" identically.

After its claimed to fix it too.

I assume you aren't commenting on the lost files here.

Nar, the chkdsk report.

I didn't get much sleep in those days so I suppose anything is possible.

Yeah, bet that's it.

But a simple delete should have showed up in the recovery bin.

Not with a folder full of very large files, those get deleted
because there isnt enough room for them in the bin.

I'd think an aberrant program would have done more damage than that.

Not if it just makes it too easy to delete a folder by not asking for confirmation of that delete.