Alan Stern wrote: > On Wed, 28 Mar 2012, Norman Diamond wrote: > >> I don't want to manhandle that old notebook's fragile vendor proprietary IDE cable again, but I'll try to find another way to test that drive again without going though USB. > > You don't have to worry about that. sg_dd works fine over USB. > >>> The USB-to-IDE bridge is vendor 067b, product 2507, Prolific Technology Inc., and usb-storage matches it for quirk 110. > > What is the bcdDevice value? Is that different from 2507? Now, if a combination of zeroing the readahead and proper user input of an sg_dd command will succeed in reading a single valid block next door to the bad block, then it won't even be necessary to unplug and replug the USB bridge. That will be good news. >>> Digression: Someone adjusts the number of blocks from the reported 39070080 (which I think is correct) to 39070079 (which I think is wrong). I'll have to install the drive in an old notebook to check if the reported number of blocks is really correct. >> >> Further on this digression: The number of blocks really is 39070080. Today libata made no adjustment and the number of blocks was correct. So some USB component makes a misadjustment to screw up the number of blocks. > > usb-storage does this, because in the past Prolific's bridges have reported the wrong number of blocks. In fact, I'm surprised that it seems to work correctly with your drive. It is hard to imagine a USB bridge adding 1 to the number of blocks. Did that really happen? Of course there are some USB bridges that f**k up the number of blocks differently, mapping each range of the drive's eight 512-byte sectors onto one 4096-byte sector that the bridge presents to the host (coincidentally the exact opposite of the mapping that modern SATA drives do internally in their firmware), and then proceeding further to conk out at the 2TB limit anyway so their f**king of the sector size and count accomplishes no benefit while still causing their damage. I can imagine a theoretical partial benefit to a Linux driver adjusting those sector sizes and counts by a factor of 8 in order to partly overcome some braindead bridges. But it's really hard to imagine a bridge adding 1 to a number of blocks and benefiting by a driver subtracting 1. (Maybe I'm just not imaginative enough.) -- 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
