Re: READ CAPACITY 16

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2008-12-17 at 11:06 -0700, Matthew Wilcox wrote:
> On Wed, Dec 17, 2008 at 09:50:52AM -0800, Grant Grundler wrote:
> > > Algorithm A (a perfect world):
> > >
> > > Issue RC16
> > >  -> If it fails, issue RC10
> > >  -> If it times out, reset the device, issue RC10
> > >
> > > Algorithm B:
> > >
> > > Issue RC10
> > > Issue RC16
> > >  -> If it succeeds, use its results in preference to those from RC10
> > >  -> If it fails, carry on with the results from RC10
> > >  -> If it times out, reset the device, carry on with the results from RC10
> > 
> > I fail to see an effective difference between Algo A and B.
> 
> Whether to issue an RC10 before issuing an RC16 or not.  It matches what
> we currently do better (we currently issue an RC10 and then issue an
> RC16 if RC10 reports we have 0xffffffff LBAs).
> 
> > The question really is one you already asked:
> > > ...The question is what to do about devices that either
> > > hang or take a long time to respond to an RC16 command.
> > 
> > A few ideas:
> > 1) maintain a blacklist
> 
> Which is obviously what we're trying to avoid doing.

I don't really see a way of avoiding this ... for USB devices it's
probably going to be a requirement.

> > 2) anything in RC10 or IDENTIFY that would clue us about RC16 functionality?
> >     If so, then something like B or C would make sense.
> 
> RC10 only returns number of LBAs and how many bytes per LBA.  I don't
> see anything in the INQUIRY data (other than the protection bit, which
> we already use to know that RC16 is supported).  We could maybe key off
> scsi_level > SCSI_2 like scsi_device_protection() does.  This would work
> for ATA SSDs because libata reports SCSI ANSI revision 05, but it won't
> work for USB devices because they get mangled down to SCSI_2, no matter
> what they support.

That latter piece is fixable.  We can also go with the INQUIRY version
descriptor information which I don't think USB mangles.

> > 3) How long does Read Capacity16 normally take?  e.g. at boot time with drive
> >    that isn't spun up yet or equivalent from RAID device.
> >    If it's not that long (e.g < 1sec or so) then just use a shorter
> > timeout in general?
> >    With parallel scanning, it should be tolerably painful.
> 
> I don't know how long it'll take.  I was hoping people with experience
> in this matter would chime in.

Actually, we can't afford to send READ CAPACITY(16) to failing devices;
some of them never come back.

James