On Wed, 2008-12-17 at 12:32 -0700, Matthew Wilcox wrote: > On Wed, Dec 17, 2008 at 02:14:09PM -0500, James Bottomley wrote: > > On Wed, 2008-12-17 at 12:11 -0700, Matthew Wilcox wrote: > > > On Wed, Dec 17, 2008 at 02:04:52PM -0500, James Bottomley wrote: > > > > Actually, we can't afford to send READ CAPACITY(16) to failing devices; > > > > some of them never come back. > > > > > > When you say 'never come back', do you mean: > > > > > > a) The drive discards the command silently > > > b) The drive hangs until a reset is issued > > > c) The drive hangs until it's power-cycled > > > d) The drive turns into a paperweight > > > > All of the above ... this is USB ... well, I don't *know* of a D > > case ... but I wouldn't bet one doesn't exist. > > The unfortunate thing is that we don't have a collection of INQUIRY > results from these devices, so we can't say whether checking for SCSI_2 > would eliminate those in categories C and D. > > Are you willing to take a patch that sends RC16 for devices claiming > SCSI_2, and falls back to RC10 if that doesn't work? Or shall I try to > implement algorithm D and talk to T10? Not really ... SCSI_2 is where the problems are. SCSI 3 would be much more acceptable. Then you can add an inquiry passthrough to USB mangling for devices you need to work. James -- 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
