🚀 go-pugleaf

Richard RUDEK <x@invalid.zeta.org.au> wrote in
message news:397b000e.4817808@news.zeta.org.au...
> Rod Speed <rod_speed@yahoo.com> wrote

> Rod, it's plain to me that there's nothing more I can say, that
> will convey what I and Svend have attempted to explain to you.

You both keep rabitting on about what wasnt even being discussed.

No one has ever disputed that the mapping between CHS
and logical blocks does indeed change with the drive type
settings used in the bios, different bios and drive overlays
that get around bios limitations at particular drive sizes.

What was being discussed was your assertion that the symptoms
that Ian saw can be produced by the use of AUTO drive settings
in the bios. You havent actually provided a shred of evidence to
support that assertion. And with the AUTO settings being the default,
even say the resetting of the cmos settings due to something the
user is unaware of happening cant produce the effect Ian saw if
the AUTO settings had been used before the failure.

> Now, you apparently are more than capable of testing whether a partition
> table will effect the choice the BIOS chooses in regards to the translation
> method used. So rather than waving your arms like a fledgling, try it.

Doesnt have the slightest relevance to what was being discussed,
whether the use of AUTO settings in the bios and the user not
changing the drive settings can produce the symptoms Ian saw.

Thats just trying what has never been disputed, that the drive
settings can affect the mapping between CHS and logical blocks.
Thats no news to anyone who knows anything about it so there
is no need to try anything and it wasnt even in dispute.

> Create a partition with the BIOS's Hard disk mode initially
> set to "Normal", then set the mode back to "Auto". What does
> the BIOS report panel say (after POST, but before the OS starts) ?

> Now try again with the mode initially set to "Large",
> then change it back to "Auto". What's reported now ?

All completely and utterly irrelevant to what was being
discussed, whether the use of AUTO setting ALL THE
TIME can produce the symptoms that Ian saw.

You aint produced a shred of evidence on that.

> But don't stop there, try other permutations of this, move
> the hard disk to another system, etc. Do you still say that
> a partition table does not effect the choice of translation modes ?

All completely and utterly irrelevant to whether the use of
the AUTO settings and not doing any of that drive moving
between systems can produce the symptoms Ian saw.

> If you now agree it does,

I have said repeatedly that I know that occurs. Doesnt have the
slightest relevance to your assertion that the symptoms Ian saw
can be produced by the use of AUTO settings and the drive staying
in the one system and not being moved around even in that system.

And it turns out he doesnt even use AUTO settings anyway.

> then it's not a complete unlikelihood some aberration could occur
> which mildly corrupts an otherwise normal LBA mode created partition
> table, such that the BIOS now decides to use another type translation
> - remember the "Auto" setting decides at some point during POST.

Wota pity he doesnt even use AUTO settings at all.

> As for wether a drive will "recal" if there is a bug in the BIOS 13h routines.

That wasnt even being discussed either. What was being discussed
was whether the drive will recal if it gets a request for a logical block
which is outside the range of logical blocks that the drive physically has.

And it aint just about recals anyway, I keep rubbing your nose in
the FACT that Ian said more than once that when he was copying
off data that he could see, that was very slow, but did happen.
THAT is the evidence that the drive was RETRYING bad sectors and
mostly getting the data eventually. That cant happen if the mapping
is producing a logical block number thats outside the range the drive
physically has. You can retry till the cows come home, you'll never
get any data out of a logical block that doesnt exist, even if the
drive is so badly designed that it does recal in that situation.

> Yes, I've had this occur, as I explained in my last message,
> although, I've not tried to do this on any recent model drives.

Doesnt have any relevance to Ian's situation where
clearly retrys did mostly get the data eventually.

> But then again, you've already questioned the adequacy of my experiments,

I've rubbed your nose FAR more in the fact that you aint
even managing to work out what is being discussed.

> so short of finding a drive that recals upon invalid LBA addresses
> and a BIOS with a bug that produces these invalid LBA addresses,
> and then have you stand next to me... well, fat chance.

And even slimmer chance of you being able to demonstrate
that that can happen with the use of AUTO drive settings.

So your original is just that, an assertion
without a shred of evidence to substantiate it.

And cant be what Ian saw because he
doesnt even use the AUTO settings anyway.

> If you had Linux, I suppose you could try using the
> "dd" command against various hard disks that you
> have, and see if reading (or perhaps writing) beyond the
> capacity of the a drive causes a recal. Nock yourself out...

Pointless even going thru the trivial exercise of writing a bit of
code that deliberately makes requests for logical blocks outside
the range that the drive has physically because that wouldnt do
a damned thing about explaining how Ian was clearly getting
retrys on the bad sectors and getting the data eventually.

Cant happen with a non existent logical block.

> Beyond all that, there's nothing more to say to you on this. Perhaps,
> try re-reading what's been already posted, with more of an open mind...

Got nothing to do with 'an open mind', its all about YOU
managing to grasp what is actually being discussed.

I repeat, no one has ever disputed that the mapping between
CHS and logical blocks does indeed vary in some situations.

That has NOTHING to do with your assertion that the use
of AUTO setting in the drive type can produce the symptoms
that Ian saw. Its just your assertion without a shred of evidence
to support it, and quite a bit of evidence like the retrys that
did get the data eventually that it cant have been a mapping
problem and was in fact a hardware problem instead.