Alan Stern wrote: > On Wed, 4 Apr 2012, Norman Diamond wrote: >> Alan Stern wrote: >>> On Tue, 3 Apr 2012, Norman Diamond wrote: >>>>>> Wrong. We CAN try to read the last block that the bridge says exists, to see if it really exists or not. (Well, only partly wrong. Maybe there really are some bridges that crash in that situation, but mine doesn't, and a broken driver still needs fixing.) >>>>> >>>>> Yes, there really are such bridges. You can find reports from people complaining about them in the email archives. >>>> >>>> Wait. Is there a bridge which overreports the last sector number by 1, and which ALSO crashes when the host PC tries to read that supposed last sector number? >>> >>> Yes. Like I said before, you can find complaints about these things in the mailing list archives. However it's not clear whether the crashing is the fault of the bridge itself or the drive it is attached to. >> >> Or the driver. > > No, it is not the fault of the driver. I agree now that my bridge's crash sometimes when trying to read bad blocks is not the driver's fault, but meanwhile my bridge does not crash when trying to read a nonexistent block so it still seems possible to detect if the result of READ CAPACITY is wrong. >> I think it is not the fault of the drive. If a drive crashed when a driver tried to access a nonexistent sector, then the drive would crash when mounted internally on an ATA or SATA cable not only when connected to a USB cable. [I think we agree on that.] > However there's no question that other bridges having the same vendor, product, and revision ID values as yours _did_ report the drive capacity incorrectly; otherwise the quirk entry would not be there. What I'm not sure of is whether those bridges went on to crash as dramatically as yours. Except that mine doesn't crash when trying to read a nonexistent block, so the quirk handling still looks overly aggressive. >> This still makes me wonder why Windows is able to handle the same bridges. > > Probably because Windows does not try to read the last block, unless it is occupied by a file. I think Windows does. At least in some cases the last block of a partition contains structural information and can't be used for files. At least in some cases Windows reports a file system error if that block can't be accessed when trying to mount the partition. Now, Windows won't have this trouble with my bridge because Windows saw the correct drive size through my bridge. Only Linux will have trouble. I'll have to see if I can create a suitable partition in Windows and then get a Linux error when trying to mount the partition without its last sector. > It would be interesting to know the details of what your Windows system does when trying to read a file that occupies the faulty sector. As mentioned in my other message a few minutes ago, now we do know more or less, but I wonder what Windows was doing previously when it obviously wasn't really reading that file. >> Now, as far as I can tell, I have found a WTF of a standard. I only have drafts of old T10 documents but it sure looks like a WTF unless something was fixed later. >> >> In SCSI Block Commands, it seems to me that the READ CAPACITY (10) command (opcode 0x25) returns the number of blocks. > > I'm not sure how you reached that conclusion. In my rather old copy of the SCSI-2 standard, section 9.2.7 (the READ CAPACITY command in the chapter on Direct-access devices) says: > > A partial medium indicator (PMI) bit of zero indicates that the > returned logical block address and the block length in bytes > are those of the last logical block on the logical unit. That's the same result that RBC promises, but my draft of SBC-3 doesn't say that. Oh, now I see it gives a hint and I missed it: "A partial medium indicator (PMI) bit set to zero specifies that the device server return information on the last logical block on the direct-access block device." That wording change was a pretty scuzzy thing to do. Not your fault of course. (Or is it ... let me check the list of committee members at the top of the document ^_^ ) -- 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
