[LSF/MM TOPIC] update on discard support & testing with vendors

[LSF/MM TOPIC] update on discard support & testing with vendors

[Ric Wheeler]

I would like to spend some time reviewing where we stand with the discard 
support - specifically review where we do in the stack (creation time, 
fine-grained during deletions, other bulk times), how the options perform and 
any performance results we have with various classes of devices (SCSI and SSD).

Similar interest in how the topology/alignment support has worked out.

Both topics took a lot of effort on our part and I expect that we are just now 
going to be hitting the point where hardware vendors take us seriously enough & 
are starting to test....

Ric

Re: [LSF/MM TOPIC] update on discard support & testing with vendors

[Mike Snitzer]

On Mon, Jan 17, 2011 at 9:46 AM, Ric Wheeler <rwheeler@redhat.com> wrote:
>
> I would like to spend some time reviewing where we stand with the discard
> support - specifically review where we do in the stack (creation time,
> fine-grained during deletions, other bulk times), how the options perform
> and any performance results we have with various classes of devices (SCSI
> and SSD).
>
> Similar interest in how the topology/alignment support has worked out.
>
> Both topics took a lot of effort on our part and I expect that we are just
> now going to be hitting the point where hardware vendors take us seriously
> enough & are starting to test....

+1

Would be nice to hear from the stake holders at the various storage
vendors (or users who have experience with said vendors'
support/performance or lack thereof).

At the last LSF, Martin and I spoke of the topology/alignment support
that was added but it generated little discussion.  Could be such
detail was too early, maybe this time around vendors will be more
vocal.

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

Discard is more sexy so I'd expect a bit more discussion for that
topic.  And again, BLOCK LIMITS VPD PAGE requirements have kept some
vendors from implementing UNMAP support (sticking with WRITE SAME w/
UNMAP bit set).

Mike

Re: [LSF/MM TOPIC] update on discard support & testing with vendors

[Martin K. Petersen]

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

Re: [LSF/MM TOPIC] update on discard support & testing with vendors

[Matthew Wilcox]

On Mon, Jan 17, 2011 at 06:38:54PM -0500, Martin K. Petersen wrote:
> Yeah, many vendors stick to reporting compliance with really old
> revisions to prevent legacy operating systems from blowing up.

That sounds like a heuristic ... :-)

> However, the SCSI folks are vehemently against having heuristics in the
> first place (guess how many USB-ATA bridge vendors actively participate
> in T10).

It's an odd situation where 99.9% of the marketshare don't participate
in the standards committee.

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

I'd love to live in their world where the device won't fall over and
refuse to respond to any further commands without a power cycle.

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