public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Ric Wheeler <rwheeler@redhat.com>,
	lsf-pc@lists.linuxfoundation.org, linux-fsdevel@vger.kernel.org,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [LSF/MM TOPIC] update on discard support & testing with vendors
Date: Mon, 17 Jan 2011 18:38:54 -0500	[thread overview]
Message-ID: <yq18vyjdrsh.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <AANLkTikihfUrLF3mMtMqYFsxqDgeQE=bv-=MN-ToY6R6@mail.gmail.com> (Mike Snitzer's message of "Mon, 17 Jan 2011 18:18:30 -0500")

>>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:

I agree that it would be great to revisit these topics at the workshop.

Mike> One nagging sticking point for some storage vendors is the Linux
Mike> requirement that a LUN advertise itself as SPC-3 compliant (in
Mike> order for Linux's SCSI layer to issue a READ CAPACITY 16, etc).

Yeah, many vendors stick to reporting compliance with really old
revisions to prevent legacy operating systems from blowing up.

However, for arrays I don't think it would be unreasonably hard to
report a different rev. if the Linux personality is set for a given
LUN. I also think it's time to get with the program for many of these
vendors. SPC-3 is about 6 years old at this point. Not exactly a spring
chicken...

However, the SCSI folks are vehemently against having heuristics in the
first place (guess how many USB-ATA bridge vendors actively participate
in T10). T10's official policy is that the device can fail any command
with any (valid) arguments at any time. And that the OS stack should
always retry with less data, try a different command variant, etc. That
might be another good topic for discussion, actually. Because while we
do have some hacks in place (use_10, etc.) things will soon get more
complex.


Mike> Discard is more sexy so I'd expect a bit more discussion for that
Mike> topic. 

Yeah, I'm about to post another TP update with the changes that were
just approved.


Mike> And again, BLOCK LIMITS VPD PAGE requirements have kept some
Mike> vendors from implementing UNMAP support (sticking with WRITE SAME
Mike> w/ UNMAP bit set).

That's fine. We can't currently benefit from UNMAP anyway. And we're
about to get better metrics for WRITE SAME.

-- 
Martin K. Petersen	Oracle Linux Engineering

  reply	other threads:[~2011-01-17 23:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-17 14:46 [LSF/MM TOPIC] update on discard support & testing with vendors Ric Wheeler
2011-01-17 23:18 ` Mike Snitzer
2011-01-17 23:38   ` Martin K. Petersen [this message]
2011-01-18  0:37     ` Matthew Wilcox

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=yq18vyjdrsh.fsf@sermon.lab.mkp.net \
    --to=martin.petersen@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lsf-pc@lists.linuxfoundation.org \
    --cc=rwheeler@redhat.com \
    --cc=snitzer@redhat.com \
    /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