On Mon, 9 Apr 2012, Norman Diamond wrote:

> > You're not thinking about it the right way.  If the quirk handling were any less agressive, it would fail to work entirely on some devices (those that crash when trying to access a nonexistent block).
> 
> I see your point, regarding devices which differ from mine, and which possibly differ from the other user in 2004 since we don't really know the reason for his crash (he might have had a bad block at or near the end of his drive).
> 
> > Such devices would not usable at all.
> 
> We are already in that situation because of the decrement.

No.  That statement is simply wrong.  Such devices are quite usable.

>  If the drive was partitioned while the drive was internally installed on an ATA cable, then the decrement now interferes with the usability of the drive regardless of whether the USB bridge really does or doesn't have a bug.

What are you talking about?  If the bridge does have the capacity bug 
then the decrement allows the bridge to be used correctly.

>  Also, if the drive was partitioned when using a known non-buggy bridge, then the same situation happens when using a bridge whose status is ambiguous because the driver does a decrement.

It is true that the current situation sometimes denies access to a
block which might work perfectly well.  But we don't have any better
solutions.  And don't forget, in any individual case it is always
possible to disable the quirk by means of a module parameter.

> > Besides, suppose this quirk entry were removed.  What would happen with the other bridges with the same ID numbers that do not decrement the block count properly?  Linux would try to access the nonexistent last block, and the access would fail.  Perhaps no unplug and replug would be needed, but any data destined for that block would be lost.
> 
> The present situation loses reads and writes of the last block when
> the last block DOES exist.

No, it doesn't; it prevents those reads and writes from being
attempted in the first place.  You probably don't care about this
distinction, however.

If you're trying to make a point in this discussion, I can't tell what
it is.  I already know that decrementing the capacity is not always the
right thing to do.  But I don't know of any better alternative.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html