Re: [PATCH] scsi: relax PAGE LENGTH check for thin provisioning UNMAP support

["Martin K. Petersen" <martin.petersen@oracle.com>]

>>>>> "Fred" == Knight, Frederick <Frederick.Knight@netapp.com> writes:

Fred,

Fred> There are no guarantees about what the T10 committee will do to
Fred> that page in the draft, or in any future versions of SBC.

Obviously.  However, we're usually pretty good at tracking the drafts
and have a pretty quick turnaround for changes.


Fred> In reality, any value > 32 (20h) will mean that you probably have
Fred> all the data you want to look at today.  YES, any device that puts
Fred> such a small value into the page length field is non-compliant
Fred> (and therefore, the contents of those fields may be non-compliant
Fred> as well).  So, allowing a value less than 3Ch would be risky.

Our main concern is that we're dealing with a ton of low-end devices
that violate the SCSI protocols in the weirdest ways.  Some return the
same blob of data regardless of which VPD page you ask for.  So when we
have a mandated value we can key off of as an extra safeguard we tend to
use it.

In this particular case it might not be such a big deal since we're
already gated by TPE being enabled in READ CAPACITY(16).  The latter is
currently restricted by the device server claiming compliance with SPC3
or better.  However, we may have to relax that criteria soon since we'll
have USB drives coming out where READ CAPACITY(10) won't cut it.  And
that opens the flood gates for random debris lingering at byte 12 and
beyond in READ CAPACITY(16).

My main concern with Mike's patch is that I think it's a bit premature
given that there's already room to grow in the current block limits VPD
and that relaxing the page length test could cause us to accept random
garbage as valid thin provisioning information.

-- 
Martin K. Petersen	Oracle Linux Engineering