Re: scrub implies failing drive - smartctl blissfully unaware

[Robert White <rwhite@pobox.com>]

Shame you already know everything?

On 11/19/2014 01:47 PM, Phillip Susi wrote:
> On 11/19/2014 4:05 PM, Robert White wrote:


>
>> One of the reasons that the whole industry has started favoring
>> point-to-point (SATA, SAS) or physical intercessor chaining
>> point-to-point (eSATA) buses is to remove a lot of those
>> wait-and-see delays.
>
> Nope... even with the ancient PIO mode PATA interface, you polled a
> ready bit in the status register to see if it was done yet.  If you
> always waited 30 seconds for every command your system wouldn't boot
> up until next year.

The controller, the thing that sets the ready bit and sends the 
interrupt is distinct from the driver, the thing that polls the ready 
bit when the interrupt is sent. At the bus level there are fixed delays 
and retries. Try putting two drives on a pin-select IDE bus and 
strapping them both as _slave_ (or indeed master) sometime and watch the 
shower of fixed delay retries.

>> Another strong actor is selecting the wrong storage controller
>> chipset driver. In that case you may be faling back from high-end
>> device you think it is, through intermediate chip-set, and back to
>> ACPI or BIOS emulation
>
> There is no such thing as ACPI or BIOS emulation.

That's odd... my bios reads from storage to boot the device and it does 
so using the ACPI storage methods.

ACPI 4.0 Specification Section 9.8 even disagrees with you at some length.

Let's just do the titles shall we:

9.8 ATA Controller Devices
9.8.1 Objects for both ATA and SATA Controllers.
9.8.2 IDE Controller Device
9.8.3 Serial ATA (SATA) controller Device

Oh, and _lookie_ _here_ in Linux Kernel Menuconfig at
Device Drivers ->
  <*> Serial ATA and Parallel ATA drivers (libata) ->
   <*> ACPI firmware driver for PATA

CONFIG_PATA_ACPI:

This option enables an ACPI method driver which drives motherboard PATA 
controller interfaces through the ACPI firmware in the BIOS. This driver 
can sometimes handle otherwise unsupported hardware.

You are a storage _genius_ for knowing that all that stuff doesn't 
exist... the rest of us must simply muddle along in our delusion...

 > AHCI SATA
 > controllers do usually have an old IDE emulation mode instead of AHCI
 > mode, but this isn't going to cause ridiculously long delays.

Do tell us more... I didn't say the driver would cause long delays, I 
said that the time it takes to error out other improperly supported 
drivers and fall back to this one could induce long delays and resets.

I think I am done with your "expertise" in the question of all things 
storage related.

Not to be rude... but I'm physically ill and maybe I shouldn't be 
posting right now... 8-)

-- Rob.