>>>>> "Fred" == Knight, Frederick <Frederick.Knight@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
