🚀 go-pugleaf

Richard RUDEK <x@invalid.zeta.org.au> wrote in
message news:39784439.1930310@news.zeta.org.au...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Svend Olaf Mikkelsen <svolaf@inet.uni2.dk> wrote
>>> Rod Speed <rod_speed@yahoo.com> wrote
>>>> Richard RUDEK <x@invalid.zeta.org.au> wrote

>>>>> I'd say, you probably ran into a side effect of
>>>>> using the "Auto" detect feature(s) of your BIOS.

>>>> I doubt it.

>>>>> If the partition table gets corrupted, it can cause the BIOS to
>>>>> decide to use a different type drive translation, other than LBA.

>>>> The bios AUTO setting doesnt use the partition
>>>> table. It just asks the drive about its parameters,
>>>> and the drive doesnt use the partition table either.

>>> This is definitely wrong.

>> We'll see.

>>> An Award BIOS with MODE set to AUTO will attempt
>>> to determine the translation from the partition table.

>> What evidence do you have for that assertion ?

> Oh shit, here we go.

> Rod, I could ask you the same question. What evidence do you
> have that the BIOS Auto setting *doesn't* use partition table data
> in the determination of the correct translation to be used...

I listed that. Most obviously with a drive which has zeros right
thru the first physical sector, there aint no geometry data to use.

And while its certainly possible for the bios to only use the geometry
data from that sector when its available, its awfully unlikely that in
Ian's case the contents of that sector got corrupted just enough to still
look like a valid partition table, but with the wrong geometry numbers.

And even if the mapping from CHS to LBA block numbers is wrong,
that does not see the drive audibly recalibrate on sector read errors,
because you still get a block number which is either within the range
the drive has or it isnt. Drives dont recalibrate when they get a
request for a block number outside the range the drive physically has.

> Quit simply, I noticed this behaviour a while back, and experimented.
> After many hours, over a few days tinkering, I came to the conclusion
> that the BIOS Hard disk "Auto" setting was indeed influenced by
> some/one of the partition table entries. I honestly can't remember
> which brand BIOS it was, but I'm prety sure it was a Pentium
> based system, thus most likely an AWARD.

That brings up the question of how adequate those experiments were.

No one disputes that the geometry data in the
MBR is indeed used for the CHS to LBA block
number mapping. Not necessarily by the bios tho.

What was being discussed was whether thats done by a bios AUTO
setting, and whether that corrupt data can result in the DRIVE seeing
read errors and audibly recalibrating when it does, and producing a
very slow copying of the data that is still visible on the drive.

Its MUCH more likely that it was actually an intermittent hardware
fault than anything to do with the AUTO setting in the bios.

> I'm much too busy ATM, to play around with some test beds
> I have here, But it is/was definately there. Try for your self...

> As to wether this played a significant role in the "errors", I cannot
> definately say, but I have had a few weird translation problems which
> produced "bad clusters" when formatted - in the one case that I can
> remember, the errors curiously occured after the ~508MB boundary, and
> was continous from there on, so I wiped the partition table and started again.

Sure, but again, thats at the OS level, not the physical drive level.

> In fact Rod, you've suggested a number of times for people
> to use a Zeroing utility of overcome some hard disk weirdities.

Yes, but thats because the OS undoubtedly uses
that data, not because the bios AUTO setting does.