On Tue, 2014-08-26 at 10:47 -0400, Alan Stern wrote: > On Mon, 25 Aug 2014, Oliver Neukum wrote: > > Just set US_FL_NEEDS_CAP16. If READ CAPACITY(16) fails in that case, > > it is clear that something is wrong. It must be set or READ CAPACITY(10) > > alone would be taken as giving a valid answer. > > You have committed a mental layering violation. :-) Indeed. > US_FL_NEEDS_CAP16 is a usb-storage flag. But the capacity > determination is made by the sd driver, which relies on the SCSI > try_rc_10_first flag. If that flag isn't set, sd tries READ > CAPACITY(16) and then falls back to READ CAPACITY(10) if an error > occurs. That's what happened here. > > I don't think we want to add another SCSI flag to say that READ > CAPACITY(10) is unreliable. Why not? It would only be friendly to tell the upper layer of a malfunction if we know about it. > > At that time we are sure that the drive will be unusable unless we > > determine the correct capacity, so we don't make matters worse if we > > crash it. > > Given the difficulty of determining the true capacity, I see two > alternatives. We could set the capacity to a ridiculously large value > (like 1 billion TB), or we could leave the capacity set to the low > value and disable the "block within bounds" checks. Neither of these > is attractive and they both have issues of their own -- although the > second is close to what Windows does. That seems to be the most attractive solution to me. > (For example, udev often tries to read the last sectors of a new drive, > looking for a GPT or RAID signature. That won't work if the capacity > is set to some random value.) Yes, but clipping has its own dangers. Suppose you use the medium without a partition table. Regards Oliver -- 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
