On Fri, 15 Jun 2012, Matthew Dharm wrote: > On Fri, Jun 15, 2012 at 11:20 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Should we go ahead and set a flag on all these devices, telling the sd > > driver to try READ CAPACITY(10) first? �That's a lot easier than adding > > more and more entries to unusual_devs.h. > > Maybe the answer to this is obvious... but, do we *know* that > READ_CAPACITY_10 will work any better in the general case of all > devices? READ CAPACITY(10) is what we were using before, when we would always set the SCSI level to SCSI_2. Now that we aren't overriding the level any more, sd sees higher values for the SCSI level and then feels free to issue READ CAPACITY(16) first. With working devices, it won't matter which READ CAPACITY is issued first. If the device reports that it doesn't support one command, sd will automatically try the other. With buggy devices, it does matter. You want to avoid issuing the non-working command, which means the working command must be tried first. I think it's a lot more common among USB devices for READ CAPACITY(10) to work and READ CAPACITY(16) to fail than the other way around. It seems quite likely that any device large enough to require READ CAPACITY(16) -- i.e., 2 TB or more -- would have proper support for both commands. If not... Well, we can always add a NO_CAPACITY_10 flag if we have to. I would be surprised if it's needed. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
