public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: linux-scsi@vger.kernel.org
Subject: READ CAPACITY 16
Date: Wed, 17 Dec 2008 09:42:10 -0700	[thread overview]
Message-ID: <20081217164210.GC19967@parisc-linux.org> (raw)


I'm looking at the UNMAP support again, and we now have a bit that tells
us whether the device supports UNMAP or not, it's called TPE (Thin
Provisioning Enabled) and is found in byte 14 of the result from READ
CAPACITY 16.  The problem is that we do our best to avoid calling READ
CAPACITY 16.

Presumably, there are many devices which do not support RC16.  That
isn't a problem, we can try RC16 and fall back to RC10 if the device
returns an error.  The question is what to do about devices that either
hang or take a long time to respond to an RC16 command.

This kind of problem isn't going to be limited to UNMAP.  DIF/DIX
already has to use RC16 to get the protection type.  Once 4k sector size
drives become common, we're going to want the "LOGICAL BLOCKS PER
PHYSICAL BLOCK EXPONENT" and the "LOWEST ALIGNED LOGICAL BLOCK ADDRESS"
information that RC16 returns and RC10 doesn't.  There's another 16
bytes and a couple of reserved 4-bit fields to be assigned too, and I
can imagine them getting used for new features in the future.

So what strategy should we adopt for trying harder to issue RC16?

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

Algorithm C:

As algorithm B, except:
 -> If it succeeds, use the RC10 results for LBA unless the LBA is 0xffffffff
    but use the RC16 results for TPE, PROT, etc.

Algorithm D:

Go back to T10 and say "Excuse me, kind sirs, would you mind adding an
INQUIRY bit to indicate that the device supports UNMAP?  I know you've
added a bit to RC16, but there's this nasty real world out there where
devices are apt to blow up if you send them an RC16 when they're not
expecting it."


Critiques should be expressed in the form of new algorithms.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

             reply	other threads:[~2008-12-17 16:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17 16:42 Matthew Wilcox [this message]
2008-12-17 17:50 ` READ CAPACITY 16 Grant Grundler
2008-12-17 18:06   ` Matthew Wilcox
2008-12-17 18:57     ` Grant Grundler
2008-12-17 19:04     ` James Bottomley
2008-12-17 19:11       ` Matthew Wilcox
2008-12-17 19:14         ` James Bottomley
2008-12-17 19:32           ` Matthew Wilcox
2008-12-17 19:36             ` James Bottomley
2008-12-17 19:49               ` Matthew Wilcox
2008-12-18  9:05     ` Boaz Harrosh
2008-12-18 14:08       ` Matthew Wilcox
2008-12-18 14:38         ` Boaz Harrosh
2008-12-18 14:49           ` Matthew Wilcox
2008-12-18 14:52           ` James Bottomley
2008-12-18 14:59             ` Boaz Harrosh
2008-12-18 20:41 ` Douglas Gilbert
  -- strict thread matches above, loose matches on Subject: below --
2008-12-17 17:20 bburk
2008-12-17 17:25 ` Matthew Wilcox
2004-12-09 14:33 read capacity 16 Frank Borich
2004-12-09 15:02 ` Christoph Hellwig
2004-12-08 21:07 Frank Borich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081217164210.GC19967@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox