Alan Stern wrote: > On Fri, 6 Apr 2012, Norman Diamond wrote: >> When sg_dd tries to read the bad block, it fails, but the bridge does not crash. >> >> When ordinary dd tries to read a Linux-length page of 8 blocks, the bridge crashes. >> >> I'm pretty sure Windows is reading a cluster of 4 blocks in the file and the bridge crashes at that time. (The partition is a little under 8MB, formatted FAT12, with clusters of 4 sectors.) > > What happens if you use sg_dd to try reading four or eight blocks including the bad block? If bpt=1 count=4 then sg_dd reads 2 good blocks, aborts on the bad block, and doesn't try the subsequent good block. The bridge does not crash. If bpt=4 count=4 then sg_dd aborts and reports that it didn't read anything. The bridge crashes. OK, this is good to know. >> Nonetheless, trying to read a nonexistent sector after the last existing sector does not crash my bridge. sg_dd reports the error correctly. Ordinary dd doesn't try to do the read because the sector address is 2 past where Linux thinks the drive ends (which is 1 past where the drive really ends). Existing non-defective blocks on the drive can still be accessed. The USB cable does not beed to be unplugged and replugged. > > What happens if you use sg_dd to try reading four or eight blocks including the first nonexistent block? With bpt=4 count=4, sg_dd aborts and reports that it didn't read anything (which is true this time). The bridge DOES NOT CRASH. However, the good news kind of seems irrelevant. 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. > 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. Around a week ago I partitioned the first 95% of someone's hard drive for exactly that reason (I could have continued and tried 99%, etc., but he said not to bother). > If you want to see the discussion that led to the quirk being added, look here: > http://marc.info/?l=linux-usb-users&m=110219110306073&w=2 > Unfortunately the critical message that had the logs attached never got into the mailing list archive. He couldn't send the log because it was too big for Hotmail. Microsoft missed their chance ^_^ After so much discussion of Windows losing data on hard drives, Microsoft should have gladly assisted a discussion of this Linux problem ^_^ >> With a different bridge, a Linux driver hangs for a few minutes after trying to read the bad block. Then it resets the bridge, the reset succeeds, and good blocks on the drive can still be accessed. Also with that different bridge, Linux knows the real size of the drive. > > The firmware on a lot of these bridges is pretty buggy. OK. However, the reset succeeded (after a delay). More importantly, the number of blocks was used accurately by Linux drivers. You will hear about this bridge again in a few minutes, in response to your other message. -- 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
