Alan Stern wrote: > On Mon, 30 Apr 2012, Norman Diamond wrote: > >> Here you are modifying my proposal. It is no problem to discuss your >> idea. At first I thought your idea was better than mine, but on >> second thought, sorry, here's a problem. Again it is because the >> broken and unbroken Prolific bridges are indistinguishable. A >> Prolific bridge could be connected to a drive whose actual usable >> capacity is a multiple of 63, or it could be connected to a modern >> drive with emulated capacity that is even (in fact a multiple of 8) >> and not usually a multiple of 63. >> >> Therefore I still favour my version. If the bridge reports an even >> number then I want to believe it, if the bridge reports a multiple of >> 63 then I want to believe it, and if neither then I want to fall back >> on the existing heuristic which performs a decrement. > > Hmmm. What about when one of the broken bridges with an older drive > reports a number which is 1 larger than a multiple of 63 but also > happens to be even? In that case your proposed heuristic would fail -- > but then so would the existing heuristic, so we'd be no worse off than > we are now. Exactly. It's not perfect but the improvements far outweigh the downside. > I still think your proposed heuristic should be handled separately from > the existing one, so that it would not be applied in situations where > we know the device is not a USB-(S)ATA bridge. OK. One quirk for bridges (accept even numbers, accept multiples of 63, and otherwise decrement) and one quirk for other kinds of devices (accept even numbers and otherwise decrement, i.e. the present heuristic). >>> As for whether we need TEST_CAPACITY...� That is still highly >>> debatable.� If we did have it, which quirk entries would use it?� So >>> far the only candidate we have is your Prolific bridge, and even there >>> it seems that the divisible-by-63 heuristic would work just as well. >> >> I wish I could get a broken Prolific bridge to test together with > > mine. Anyway the divisible-by-63 heuristic would work better than > > the existing heuristic but it would not work as well as > > TEST_CAPACITY. My proposed modified heursitic would usually work > > better than the existing heuristic but not as well as TEST_CAPACITY. > > How do you know? You haven't read through ten years' worth of email > messages on this subject, have you? You're going on the basis of your > experience with _one_ bridge and a couple of drives. Because we do know there are a lot of multiples of 63 out there, and because if the bridge reports a capacity that is a multiple of 63 (i.e. maximum LBA one less than a multiple of 63) and we try reading that last block then it should be read successfully. The only time we have to worry about TEST_CAPACITY is a pretty rare case -- and even in such rare cases, we don't know if the bridge will always hang in those cases. My bridge appeared to hang on reading multiple nonexistent blocks but not on reading a single nonexistent block, and at this moment it looks like it might not even be the bridge's fault (I have to test it on more drives). > By the way, have you tried connecting your bridge to a CD/DVD drive? I have read CDs through it. I never thought of inquring the capacity. >> By the way, a while back you asked what happens if I use sg_dd to try >> reading multiple blocks including the last existing block and some >> non-existing ones. The answer seems to depend on the drive as well >> as the method of connection (USB-to-PATA vs. eSATA plus >> SATA-to-PATA). With the drive that I've usually been using I think >> the drive hangs so we can't really figure out whether to blame the >> bridge. With a different drive the drive reports the error but sg_dd >> and Linux drivers do something to retry so many times that after 30 >> minutes I lost patience waiting for sg_dd to finish and report its >> error. > > Indeed -- that's exactly the sort of thing which could happen with > TEST_CAPACITY. It's one of the reasons I'm cautious about adding > TEST_CAPACITY and an example of why TEST_CAPACITY might not work as > well as you think. Correction: Therefore TEST_CAPACITY should not try to read multiple blocks in one read. Your other message says you have a different model of Prolific bridge which has the capacity bug but which is (sadly at this moment) distinguishable from mine. Anyway, what happens if you try to read the last block that the bridge asserted to exist? Also for curiosity what happens if you try to read multiple nonexistent blocks, but that curiosity is irrelevant to the single block that TEST_CAPACITY would try to read. -- 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
