On Mon, 2012/5/7, Alan Stern wrote: > On Mon, 7 May 2012, Norman Diamond wrote: >> I am pretty sure that Windows XP did not try a READ CAPACITY(16) in >> that case but Windows 7 did. I cannot be completely sure because I >> found two free USB snoopers, one of which worked on Windows XP but is >> documented as not working on Windows 7, and one of which didn't even >> work on Windows XP or at least did not work as documented. But it >> doesn't matter. At least two broken bridges are broken worse than >> that. >> >> Quoting your proposed patch for the purpose of discussion: >> >>> Index: usb-3.4/drivers/scsi/sd.c >>> =================================================================== >>> --- usb-3.4.orig/drivers/scsi/sd.c >>> +++ usb-3.4/drivers/scsi/sd.c >>> @@ -1902,7 +1902,7 @@ static int sd_try_rc16_first(struct scsi >>> return 1; >>> if (scsi_device_protection(sdp)) >>> return 1; >>> - return 0; >>> + return 1; >>> } >>> >>> /* >>> >>> >> > > That accords with what I think Windows does. > > Is that just your guess or do you have evidence for it? > > You said that Windows XP doesn't use READ CAPACITY(16), which means it > is certainly not in accord with the patch. Right, in that sentence where I said Windows, I should have said Windows Vista and later. > And you said that the USB > snooping programs didn't work right under Windows 7, which means you > don't know what Windoes 7 actually does. In my case there is no other way that a host (PC or other, any OS or driver) could obtain a reported capacity past the 2.2TB mark. Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of an ATA Identify command though I haven't seen one. >> But broken bridges look pretty broken. I'm guessing upon guessing >> again, but it looks like some broken bridges respond correctly to >> READ CAPACITY(16), wrap around instead of responding correctly to >> READ CAPACITY(10), AND: wrap around instead of responding correctly >> to READ(16). Just because a bridge can handle 3TB for READ >> CAPACITY(16) doesn't mean it can handle that for READ(16) or >> WRITE(16). > > Very broken indeed. How did you determine this? Before sending my previous mail which you were responding to here, I observed that through a non-broken bridge, Windows 7 correctly displayed the NTFS partitions, but through a broken bridge, Windows 7 displayed some of the partitions as RAW, suggesting that commands to read the NTFS structures actually read other sectors. Subsequently I experimented with reformatting the partitions that were displayed as RAW, watched Windows detect the results as NTFS, wrote some files to them, and watched Windows redetect the first partition in the drive, which used to be NTFS, as now being RAW. I think the GPT partition structure survived because Windows cached it in RAM, but it wouldn't have survived overwrites on disk. >> I have a feeling we have to do both READ CAPACITY(10) and READ >> CAPACITY(16), and if we see wraparound then we should either truncate >> the drive to 2.2TB or avoid the drive entirely. I think truncation >> is safe enough at this point -- if a partition gets truncated then >> subsequent attempts to mount will fail, so any existing but >> inaccessible data will be safe from harm, while accessible data will >> be read and written correctly. > > That sounds like the best approach. You would want to do this for all > USB drives? Or only those known to be (S)ATA bridges? I think it's needed with [S]ATA bridges, whether or not we know that they're bridges. I think it's probably not needed with anything else, but it probably doesn't hurt to do it with anything else. Therefore it's probably safest to do it with all USB drives. -- 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
