Alan Stern wrote: > On Mon, 9 Apr 2012, Norman Diamond wrote: >> I suggest that quirk processing should only try to read 1 block, the last block which is asserted to exist, and decrement if the read fails due to non-existence. If the read fails for a different reason then the block exists and the count should not be decremented. > > I have tried to explain before that this is a very bad idea. Bridges that crash when attempting to read beyond the end of the device would become totally unusable. In cases where a bridge has been observed to crash when trying to read a SINGLE block which the bridge asserted to exist but which didn't actually exist, I agree that an aggressive quirk is needed. In cases where a bridge has been observed to crash when trying to read MULTIPLE blocks among which one block had a problem, there is no evidence yet to judge that my idea is very bad. Those bridges need to be tested again with single block reads, and need to be tested on reading the last block number which the bridge asserts to exist rather than attempting to read an existing bad block (by coincidence the two might be the same block, but not usually). >>> By the way, Linux's SCSI disk driver no longer does this. It is more cautious; accesses near the end of a USB device are broken up into single-block reads or writes. However at the time the quirk entry was added, the driver wasn't so careful. >> >> Which means that someone's bridge might have crashed due to a bad block at or near the end of the drive. > > More likely the bridge crashed because it was unable to handle a multiple-block read whereas it could have handled a single-block read. My intuition agrees with your comparison of the probabilities. Now I think we agree that the existing handling of quirks is too aggressive for some bridges. > Regardless, we are now stuck. We don't dare remove the existing quirk entries because of the potential for breaking systems that currently work. If you can suggest a way of detecting whether or not the capacity value is correct that will not break any existing systems, I would be extremely glad to hear it. We do know that the existing handling is broken because Linux did truncate my NTFS partition yesterday. Linux reported that it was truncating, and although each driver didn't know what the reason was, you and I know the reason: one driver truncated the drive and the next driver saw a partition structure extending past the truncated drive so it truncated the partition. I suggest further testing to see which quirks can be handled less aggressively. For example with newer instances of firmware 1.00 of the Prolific chip, we know that we can try to do a single block read of the last block that the chip asserts to exist, so we can test whether that block really exists (and remember not to count it out if it exists but has media errors). With older instances of firmware 1.00 of the same Prolific chip, we don't know for sure, but we do know that previous testing wasn't adequate. In cases where chips and volunteers are available, sg_dd provides pretty quick testing. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
