Wierd chkdsk issue

[Curious George]

Nope.

LOL. Without a perfectly functioning ECC system they are completely
useless.

Nope.

I guess you never bothered to compare it to anything

Waffle.

LOL.

said the king of waffles:

[David A. Flory]
BTW, Chkdsk can report errors where there aren't any.

[Rod Speed]
Thats file system errors tho, not bad clusters.

Nope, its just basic mathematics.

except when the electronics responsible for it are flaking out

We've had those for years now.

Problem is they're not very good.

Copout.

Guess you're not familiar with an attention span.

Only a fool has ever claimed its anything even remotely
resembling anything like any 'great salvation'

No. Fools call them "good reporting and diagnostic mechanisms"

It does however accurately report the number of soft errors and hard errors.

Meanwhile only "Approximately 30% of failures can be predicted by
S.M.A.R.T." It's pathetic.
http://en.wikipedia.org/wiki/Self-Monitoring,_Analysis,_and_Reporting_Technology

Even you should be able to find plenty of examples using google and groups.google.

No I want better than Usenet rumor or _ass_umption. Meanwhile typical
group advice is that chkdsk output with bad clusters indicated coming
failure. Even when no bad sectors are identified.

Nope, because reallocated sectors will show up in the
SMART report and that doesnt explain why restoring the file
to a different hard drive produces the same chkdsk report.
OK.

chkdsk DOES NOT AND CANNOT ANALYSE FILES FOR
PROBLEMS, ALL IT CAN EVER DO IS ANALYSE AND
OPTIONALLY REPAIR PROBLEMS WITH THE FILE SYSTEMS.

but chkdsk /f found nothing. The *file* at least *appears* to be
tripping the chkdsk /r problem (on the other disk).

I'm still unclear how the filesystem was damaged and apparently
unrepairable via chkdsk. Filesystem damage, I might add, that chkdsk
/f can't see. and is reproduced by copying over the questionable
files.

chkdsk has no way of knowing that since by definition
the drive will only reallocate bad sectors on writes and
after that has been done, its invisible to chkdsk.

Reallocation happens when the HDD sees *either* a read or write error.
It is all supposed to be invisible, but something is weird.

FWIW ActiveSMART has flagged "Raw Read Error Rate" as changing too
much and estimated a TEC date this month.

 

[teckytim]

Ok everybody stop fighting. I think it's solved.

I have found a couple anecdotal Usenet reports of chkdsk having trouble
with 8+ gig files with NTFS compression attribute. My problem files,
however, are 4+ gigs. I'm currently checking out the theory. It does
seem plausible according to my preliminary investigation.

I think it's pretty strange or, rather, horrifying that this issue
exists and doesn't seem to be widely discussed or known. Having,
say, a mult-igig DVD ISO or system backup file on a compressed NTFS
disk is not exactly exotic now adays.

 

[Folkert Rienstra]

(edited for brevity)


I didn't intend to imply any comparison or history.

No?
What else could you have intended with including "modern" and "high capacity"

I guess this comment is also misleading as I'm more concerned
about drive > electronics than disk surfaces per se.

I think you are one of those babblebots that doesn't think over
anything he says just replaces one uncareful thought with another.

So out goes this comment then.

Although I don't want to go further OT I don't think SMART is the
great salvation it purports to be.

Wich is further OT, yes. A lot of the S.M.A.R.T. values are merely in-
formational, information that you didn't have on pre SMART era disks,
so you were "blissfully unaware of what was going on" under the hood.

But more importantly, are you aware of instances where chkdsk
*erroneously* reports bad clusters?

Nope, and I don't remember reading in your posts that such an instance
even ocurred.

Or is it safe to assume that in my case no bad sectors were re-
ported because the drive remapped them (rather than chkdsk)?

That would not make sense at all. That would mean it does 2 checks,
one that runs it in to the supposedly bad cluster and a second that
goes to check which sectors of the cluster are bad. While that isn't
entirely unfeasable (apart from what the point of it is) it shouldn't
report clearly conflicting results. Either the cluster is bad or it isn't.
If the cluster is bad then there have to be bad sectors.

I strongly suspect that some of the reported info is from what is re-
corded within the file system, whether old or just previously updated
from the session, but not necessarily detected during the session.

Or that chkdsk erroneously *believes* these sectors were remapped
by the drive?

It's very likely too ancient to even be aware of such drive features.

 

[Folkert Rienstra]

"Curious George" AKA "teckytim"

Without a perfectly functioning ECC system they are completely useless.

Not "completey" useless, just a lot slower and irregular in transfer speed.

Nope.

I guess you never bothered to compare it to anything

Yup.


LOL.

said the king of waffles:

[David A. Flory]
BTW, Chkdsk can report errors where there aren't any.

[Rod Speed]
Thats file system errors tho, not bad clusters.

Nope, its just basic mathematics.

except when the electronics responsible for it are flaking out

Has nothing to do with "modern" and "high capacity" either.

Problem is they're not very good.

Problem is that indicators can be conficting (eg normalized
vs raw) and you don't know exactly which one is false.

Guess you're not familiar with an attention span.


No. Fools call them "good reporting and diagnostic mechanisms"


Meanwhile only "Approximately 30% of failures can be predicted by S.M.A.R.T."
It's pathetic.
http://en.wikipedia.org/wiki/Self-Monitoring,_Analysis,_and_Reporting_Technology


No I want better than Usenet rumor or _ass_umption. Meanwhile typical
group advice is that chkdsk output with bad clusters indicated coming
failure. Even when no bad sectors are identified.

Then what's the surface scan for.

but chkdsk /f found nothing. The *file* at least *appears* to be
tripping the chkdsk /r problem (on the other disk).

I'm still unclear how the filesystem was damaged and apparently
unrepairable via chkdsk. Filesystem damage, I might add, that chkdsk
/f can't see. and is reproduced by copying over the questionable files.

Reallocation happens when the HDD sees *either* a read or write error.

Nope, not necessarily. It has to see a fair number of read retries.
And on current disks there are no write errors anymore except for
those that do writechecks on the first hours of operation in their life.

It is all supposed to be invisible,
Nope.

but something is weird.

FWIW ActiveSMART has flagged "Raw Read Error Rate" as changing too
much and estimated a TEC date this month.

Check the power supply to that drive.

 

[Folkert Rienstra]

Ok everybody stop fighting. I think it's solved.

I have found a couple anecdotal Usenet reports of chkdsk having trouble
with 8+ gig files with NTFS compression attribute. My problem files,
however, are 4+ gigs. I'm currently checking out the theory. It does
seem plausible according to my preliminary investigation.

I think it's pretty strange or, rather, horrifying that this issue
exists and doesn't seem to be widely discussed or known. Having,
say, a mult-igig DVD ISO or system backup file

on a compressed NTFS disk is not exactly exotic now adays.

So you went from a noncompressed to a compressed NTFS disk, George?
Something you completely forgot. Right. Why does this smell of troll?

 

[Rod Speed]

Ok everybody stop fighting.

No one is fighting except you, child.

I think it's solved.

I have found a couple anecdotal Usenet reports of chkdsk having
trouble with 8+ gig files with NTFS compression attribute. My
problem files, however, are 4+ gigs. I'm currently checking out the
theory. It does seem plausible according to my preliminary investigation.

Yes, all the evidence points to the possibility that its a quirk of chkdsk, like I said.

I think it's pretty strange or, rather, horrifying that this issue
exists and doesn't seem to be widely discussed or known.

Why when its just a blemish and isnt fatal ?

Having, say, a mult-igig DVD ISO or system backup file on
a compressed NTFS disk is not exactly exotic now adays.

But presumably the quirk isnt always seen in that situation
and thats the reason it managed to get out in the field like
that. Its likely only seen with some other detail as well etc.

 

[Rod Speed]

I never saw this post of yours for some reason, just ****nut's response to it.

LOL.

Village eejut imitations cut no mustard around here, child.

Without a perfectly functioning ECC system they are completely useless.

Irrelevant to whether they are 'pretty sketchy' or not.

ECC is a bulletproof technique that allows higher bit densitys, stupid.

I guess you never bothered to compare it to anything

Guess again, child.

LOL.

Village eejut imitations cut no mustard around here, child.

said the king of waffles:

Never ever could bullshit its way out of a wet paper bag.

[David A. Flory]
BTW, Chkdsk can report errors where there aren't any.

[Rod Speed]
Thats file system errors tho, not bad clusters.

That aint waffle, ****wit child.

except when the electronics responsible for it are flaking out

No different to any other electronics, ****wit child.

Problem is they're not very good.

Mindless pig ignorant drivel.

You're so stupid that you cant understand it ? YOUR problem, as always.

Guess you're not familiar with an attention span.

Never ever could bullshit its way out of a wet paper bag.

Yep.

Fools call them "good reporting and diagnostic mechanisms"

Never ever could bullshit its way out of a wet paper bag.

Meanwhile only "Approximately 30% of failures can be predicted by S.M.A.R.T."

Different matter entirely. Plenty of faults produce no evidence of impending failure, cretin.

If the drive stops spinning up, because the rotation system has failed,
you wont normally see any indication that that is about to happen, most
obviously when its something as basic as a failed driver transistor etc.

It's pathetic.

You're pathetic.

http://en.wikipedia.org/wiki/Self-Monitoring,_Analysis,_and_Reporting_Technology

No I want better than Usenet rumor or _ass_umption.

You have always been, and always will be, completely and utterly irrelevant.

What you might or might not want in spades.

Meanwhile typical group advice is that chkdsk output with bad clusters
indicated coming failure. Even when no bad sectors are identified.

You're lying now.

but chkdsk /f found nothing. The *file* at least *appears*
to be tripping the chkdsk /r problem (on the other disk).

Thanks for that completely superfluous proof that you have never ever had a ****ing clue.

I'm still unclear how the filesystem was damaged and apparently
unrepairable via chkdsk. Filesystem damage, I might add, that chkdsk
/f can't see. and is reproduced by copying over the questionable files.

Its just a quirk of chkdsk that gets it wrong with that file, stupid.

Reallocation happens when the HDD sees *either* a read or write error.

Wrong. Reallocation does NOT happen with read errors, essentially
so you can attempt to recover the data out of that bad sector.

It is all supposed to be invisible,

Nope. Thats just what the fools that dont understand the reallocation system assume.

but something is weird.

Yep, chkdsk is having a brain fart, stupid.

FWIW ActiveSMART has flagged "Raw Read Error Rate"
as changing too much and estimated a TEC date this month.

Can be due to a number of things like drive temp and power supply
and stuff as basic as you kicking the case in one of your tantrums.

 

[teckytim]

No?
What else could you have intended with including "modern" and "high capacity"

It a simple statment of fact about current drives suggesting that areal
denity (high capacity) is to balme.

I think you are one of those babblebots that doesn't think over
anything he says just replaces one uncareful thought with another.

And with all your great care you led me directly to the solution.

So out goes this comment then.

Ahh. Another carefully worthless response.

Wich is further OT, yes. A lot of the S.M.A.R.T. values are merely in-
formational, information that you didn't have on pre SMART era disks,
so you were "blissfully unaware of what was going on" under the hood.

And most users are still blissfully unaware even with smart. Many
either do not access them or only look to see whether SMART values fall
within permitted limits. Few actually track changes in error rates in
a meaningful way. Most 3-rd party SMART software that attempts to do
that fail miserably with totally meaningless TEC predictions.

Nope, and I don't remember reading in your posts that such an instance
even ocurred.

Then please take more care and read the initial post.

 

[teckytim]

Yes, all the evidence points to the possibility that its a quirk of chkdsk, like I said.

Right. It was a good guess. Although it's not clear, as you
suggested, it is a likely flaw due to NTFS's complexity. NTFS is not
as horrible as you purport.

It's too bad you weren't familiar with the bug. It would have saved a
lot of bandwidth. Plus there's no need to simply ignore it and bury
one's head in the sand as you suggest. There's a work-around i.e.
either don't compress >4gig files or break them into smaller ones.
Easy to do with Vmdisks and disk images. A MS report also warrants
filing. It should be very fixable.

Why when its just a blemish and isnt fatal ?

Because it's a bug that appears in a completely un-exotic scanario. It
also has ramifications. Users who see this msg may either not trust
healthy disks or not trust that when chkdsk was "recovering bad
sectors" that it didn't screw that up too.

But presumably the quirk isnt always seen in that situation
and thats the reason it managed to get out in the field like
that. Its likely only seen with some other detail as well etc.

Perhaps it is also related to cluster size or some other configuration
variable which is why it gets noticed by different users at different
thresholds. Then again the other user may simply not have had any
files between 4-8gigs. We don't know.

 

[teckytim]

So you went from a noncompressed to a compressed NTFS disk, George?

Who? No.

Something you completely forgot. Right. Why does this smell of troll?

I don't care what you think. You weren't any help.

How am I a troll? Becasue your ego is bruised by publically not
knowing about the problem? I suppose all posters need to bow down and
grovel when they're received no real answer.

Have a nice day.

 

[Rod Speed]

Right. It was a good guess.

Wasnt a guess. Just an analysis of the evidence.

Although it's not clear, as you suggested,

Corse it is. Nothing else explains the evidence.

it is a likely flaw due to NTFS's complexity.

What I said originally.

NTFS is not as horrible as you purport.

Never ever said anything even remotely resembling anything like that.

It's too bad you weren't familiar with the bug.

Not even possible to be aware of all quirks of chkdsk, child.

It would have saved a lot of bandwidth.

There's no shortage of bandwidth, ****wit child.

Plus there's no need to simply ignore it and
bury one's head in the sand as you suggest.

Never ever 'suggested' anything of the sort.

There's a work-around i.e. either don't compress

Or just realise that its a just a quirk of chkdsk and dont bother to do anything.

Easy to do with Vmdisks and disk images. A MS
report also warrants filing. It should be very fixable.

Unlikely they arent aware of it already, and no one
is stopping you from filing anything you like, child.

Because it's a bug that appears in a completely un-exotic scanario.

Only a fool is horrified about something like that.

It also has ramifications.
Nope.

Users who see this msg may either not trust healthy
disks or not trust that when chkdsk was "recovering
bad sectors" that it didn't screw that up too.

Their problem.

Perhaps it is also related to cluster size

Unlikely unless you arent using the default cluster size.

or some other configuration variable which is why it
gets noticed by different users at different thresholds.
Duh.

Then again the other user may simply not have had any files between 4-8gigs.

Plenty do now with PVRs so common now.

We don't know.

Corse we do on that last.

 

[Rod Speed]

Folkert Rienstra wrote

It a simple statment of fact about current drives suggesting that
areal denity (high capacity) is to balme.

Pity we have seen the same soft error rate for many years now.

And with all your great care you led me directly to the solution.

Ahh. Another carefully worthless response.

Must be one of those rocket scientist ****wit children.

And most users are still blissfully unaware even with smart.
Irrelevant.

Many either do not access them or only look to see
whether SMART values fall within permitted limits.

Very few do more than the first.

Few actually track changes in error rates in a meaningful way.

Few need to.

Most 3-rd party SMART software that attempts to do that
fail miserably with totally meaningless TEC predictions.

Better than nothing if the important attributes are changing significantly.