On Fri, 4 May 2012, Norman Diamond wrote: > Alan Stern wrote: > > On Thu, 3 May 2012, Norman Diamond wrote: > >> Alan Stern wrote: > >>> On Thu, 3 May 2012, Norman Diamond wrote: > >>>>> It looks like the bridge is sending just the least-significant 32 bits > >>>>> of the capacity.� What it should have done is reply with 0xffffffff. > >>>>> Then the kernel would know to try again with a READ CAPACITY(16) > >>>>> command, which is capable of retrieving values larger than 32 bits. > >>>> > >>>> You are right, bridges' failures to reply with 0xffffffff are > >>>> bridges' bugs. Obviously Windows proceeded to try a READ > >>>> CAPACITY(16) regardless. > >>> > >>> Don't be so sure. I have seen reports from others indicating quite > >>> clearly that Windows would believe a partition table even when it > >>> contradicted a device's reported capacity. > >> > >> Yes, but Windows didn't see the entire asserted partition, Windows > >> saw the reported size of the drive and the asserted size the > >> partition and the accessible area of the partition. > > > > Presumably you are referring here to your own experience rather the > > reports from others mentioned above. > > There is no contradiction. I observed that Windows saw the asserted > size of the partition, and that Windows used the accessible area of > the partition when such use was not prevented by truncation at the > drive's reported capacity. Sure, that's what Windows did during your test. But you have no direct way of knowing what happened during tests reported years ago by people using other versions of Windows. > When Windows needed to access the trailing sectors of the partition > but they were inaccessible due to the drive being smaller, Windows > did not mount the partition. Now this part of it is my experience, > but you don't cite contradictory reports on this. I can't cite them because I haven't tried to try tracking them down in the mailing list archives (not an easy task at best). Still, as far as I can remember, the reported experiences _did_ contradict what you observed. However I don't want to make any strong claims, because my memory _is_ fallible. Mainly I just want to point out that some of what you claim as fact is really inference and jumping to conclusions on insufficient evidence. > >> In the test mentioned here, Windows saw the entire drive size, which > >> had to come from READ CAPACITY(16). > > > > Perhaps so.� I'd feel a lot more confident about that conclusion if > > there was a USB trace. > > We know that it didn't come from READ_CAPACITY(10), and we know that > it didn't come from believing the partition table. When the same You don't "know" these things -- you infer them from the observed behavior. > drive was connected through an incredibly stupidly broken adapter, > Windows saw the partition table near the beginning of the drive, > could not access the mirror of the partition table (GPT) at the end > of the drive, and displayed the physical drive size that the > incredibly stupid broken adapter reported (the infamous size 2.2TB). > A partition table, whether accurate or not, does not overcome the > physical size that any OS can access. That wouldn't necessarily prevent Windows from allowing a partition to be mounted even though it extended beyond both the reported end of a device and the physical end, particularly if the filesystem on that partition did not have important data structures stored at the end. > > Different versions of Windows may behave differently.� It might also > > depend on the partition type -- it may even depend on the drive > > attached to the bridge. > > Well yeah some versions of Windows can't see more than 504MB > regardless, or can't see more than 32GB regardless, or can't see more > than 137GB regardless. How about if we ignore those? (Except, let's > laugh at Windows 3.1 that divided by zero while trying to format the > second partition on a 1GB drive ^_^) I wasn't referring to those systems anyway. > Yes it depended on the partition type because FAT16 doesn't have part > of its structure mirrored in trailing sectors. Also again it depends > on some versions of Windows because the non-NT series couldn't > natively access NTFS partitions. > > Nonetheless, no matter how much Windows believes a partition table, > it cannot access sectors that a drive's DCO or a broken adapter > prevent access to. That is obvious and irrelevant to our discussion. > > That's right. > > You'll be happy to hear that my Prolific bridge responds with an > > Illegal Request error code.� That's with a rather old drive which can > > hold only 80 GB. > > That's good. > > > I also tested my JMicron bridge.� It has the same vendor and product > > IDs as yours (152d:2338).� It doesn't have the capacity bug.� It does > > not recognize READ CAPACITY(16) (fails with Illegal Request). > > That's bad. Your failing one is indistinguishable from mine which I > still think must be working. It may be a function not of the bridge but of the drive connected to the bridge. I don't have any drives to test that are > 2 TB. You should test your bridges with sg_raw, if you can't easily build a new kernel. The command to use is: sg_raw -r 32 /dev/sgX 9e 10 0 0 0 0 0 0 0 0 0 0 0 20 0 0 (16 bytes total in the CDB, and fill in the X with the appropriate number). > > When > > asked to read a collection of blocks any of which extend beyond the > > end of the drive, it returns immediately with no data and no error > > indication -- which obviously is not ideal but it's better than > > hanging. > > But that test was only for curiosity. TEST_CAPACITY only needs to > try to read the last single block that is asserted to exist; it > doesn't need to read a collection. Well, one of the collections I tested was a singleton, consisting of nothing but the one block following the the physical end of the drive. Alan Stern -- 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
