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-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
