On Tue, 3 Jul 2012, James Bottomley wrote: > > What happened is that T10 > > in their infinite wisdom decided to put things like "supports TRIM" and > > "is actually a 4k block size but fakes 512 byte blocks" in the Read > > Capacity 16 results. So if we want to support those kinds of things > > (and I think we do), then we need to send Read Capacity 16 to devices. > > > > It's not about "enterprise features" at all, but about supporting the > > next generation of standard consumer drives. I'm tempted to say the > > USB Storage driver needs to go back to the way things were, because I > > don't see any other way to fix this. > > But anyway, we're stuck ... we have to send RC16 first to support these > features. We did protest to T10 at the time, but to no avail. Does it have to be sent _first_? Or would it be okay to send _both_ commands and believe the RC10 capacity rather than the RC16 capacity if they differ? > > I have no idea what Windows is doing to support these features. That > > might be a fruitful course of investigation. > > Hopefully one of the USB people can do this. > > I still think a whitelist of USB devices sending proper SCSI level > information in the inquiry might be the best way forward. I'm doubtful. It wouldn't be at all surprising for devices to claim they support a particular level when in fact they support some but not all of the required commands. Then what do you do? Put them on the whitelist because of the commands they support, or leave them off because of the other ones? What happens later on when you decide to use more of the required commands? Alan Stern -- 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
