Re: scrub implies failing drive - smartctl blissfully unaware

[Phillip Susi <psusi@ubuntu.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/19/2014 4:05 PM, Robert White wrote:
> It's cheaper, and less error prone, and less likely to generate
> customer returns if the generic controller chips just "send init,
> wait a fixed delay, then request a status" compared to trying to
> "are-you-there-yet" poll each device like a nagging child. And you
> are going to see that at every level. And you are going to see it
> multiply with _sparsely_ provisioned buses where the cycle is going
> to be retried for absent LUNs (one disk on a Wide SCSI bus and a
> controller set to probe all LUNs is particularly egregious)

No, they do not wait a fixed time, then proceed.  They do in fact
issue the command, then poll or wait for an interrupt to know when it
is done, then time out and give up if that doesn't happen within a
reasonable amount of time.

> 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.

> 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.  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.

> Another common cause is having a dedicated hardware RAID
> controller (dell likes to put LSI MegaRaid controllers in their
> boxes for example), many mother boards have hardware RAID support
> available through the bios, etc, leaving that feature active, then
> the adding a drive and

That would be fake raid, not hardware raid.

> _not_ initializing that drive with the RAID controller disk setup.
> In this case the controller is going to repeatedly probe the drive
> for its proprietary controller signature blocks (and reset the
> drive after each attempt) and then finally fall back to raw block
> pass-through. This can take a long time (thirty seconds to a
> minute).

No, no, and no.  If it reads the drive and does not find its metadata,
it falls back to pass through.  The actual read takes only
milliseconds, though it may have to wait a few seconds for the drive
to spin up.  There is no reason it would keep retrying after a
successful read.

The way you end up with 30-60 second startup time with a raid is if
you have several drives and staggered spinup mode enabled, then each
drive is started one at a time instead of all at once so their
cumulative startup time can add up fairly high.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUbQ/qAAoJEI5FoCIzSKrwuhwH/R/+EVTpNlw36naJ8mxqMagt
/xafq+1kGhwNjLTPV68CI4Wt24WSGOLqpq5FPWlTMxuN0VSnX/wqBeSbz4w2Vl3F
VNic+4RqhmzS3EnLXNzkHyF2Z+hQEEldOlheAobkQb4hv/7jVxBri42nMdHQUq5w
em181txT8zkltmV+dm8aYcro8Z4ewntQtyGaO6U/nCfxt9Odr2rfytyeuSyJi9uY
+dKlGSb5klIFwCOOSoRqEz2+KOFHF7td9RrcfIRcPRgjKROH0YilQ8T53lTMoNL1
aUMsbyUy+edEBN1a4o/FqK3dEvBSu1nnRGRpSgm2fFGKhyi/z9gmJ1ZXTdYZRXE=
=/O7+
-----END PGP SIGNATURE-----