On Tue, 1 May 2012, Norman Diamond wrote: > >> 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. We don't know, but our experience has not been good. Even if the bridge doesn't hang, it is quite possible the kernel will get stuck in a very long, very slow retry loop. Maybe not as bad as the loop you experienced while testing a different scenario, but still bad. > >> 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. To repeat: You have no way of knowing whether reading a single block will avoid this problem when other bridges are used. > 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? It behaves the same way yours does: immediate failure with no error information. > 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. I tried multiple experiments, reading 8 blocks starting at different positions relative to the end. In each case, if any of the blocks were after the physical end of the drive, the bridge returned immediately with no data and no error information. I also have another bridge to test, a very buggy device made by JMicron. I don't remember whether it has the capacity bug, and I don't have time to work on it today. I'll let you know how it behaves later on. Alan Stern -- 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
