Alan Stern wrote: > On Wed, 11 Apr 2012, Norman Diamond wrote: [Alan Stern:] >>> It sounds like you are suggesting that we have a new quirk, something like TEST_CAPACITY. When this quirk is present, we could attempt to read the last block when the drive (or media) is first detected, thereby determining whether the reported capacity needs to be adjusted. >> >> Yes, that is what I've been suggesting for a while. But at this moment I might have a better suggestion, discussed below. Or it might be better to combine the two ideas. >> >>> The existing FIX_CAPACITY and CAPACITY_HEURISTICS quirk entries could be changed to TEST_CAPACITY as people report the results of their testing. However this would be a very slow process. >> >> FIX_CAPACITY will still be necessary in cases where a bridge is known to have both problems, always overreporting and crashing when tested for overreporting. I think these cases will be a small minority though. > > Your naive faith in the high quality of the firmware in low-cost consumer electronic devices is touching, but sadly misplaced. Well, I thought this particular combination of two bugs would be caught very quickly because such devices would even be unusable in Windows, but now I guess you might be right. > Besides, your initial conclusion is wrong. FIX_CAPACITY will apply well in cases where a bridge is known to have the overreporting bug. Even if the bridge doesn't crash when asked to read beyond the end of the drive, there's no reason to do such a test if we know in advance what the answer will be. Now you're the one being naive ^_^ You THOUGHT you knew in advance that a particular bridge is known to have the overreporting but, where in fact in some secret revisions it doesn't and in some secret revisions we're not quite sure, missing a log and missing a test sample for further testing. How can we be sure that other bridge manufacturers don't also make secret revisions? (Even the firmware revision number that you get from a hard drive doesn't tell you which firmware revision it really was, unless you know the vendor's proprietary protocol to get it. "Specifications subject to change without notice" says "without notice" and means "without notice" and really means it.) > The only real reason for the new TEST_CAPACITY flag would be to handle cases where some devices get the capacity wrong and others with the same IDs get it right. This means that initially only two quirk entries would require the TEST_CAPACITY flag: the one for your device and the single entry that currently uses CAPACITY_HEURISTICS. Well, you already told us why the one that currently uses CAPACITY_HEURISTICS might not be suitable for converting to TEST_CAPACITY unless more testing is done to show that it won't crash ^_^ >> Now, I think that most of the existing FIX_CAPACITY cases probably should be changed to CAPACITY_HEURISTICS. This will be simpler and quicker, though not maximally accurate by itself. > > Definitely NOT! One of the most important rules we have in kernel development is that we do not break existing systems. It is known that there are devices which overreport and for which the actual number of blocks is odd; we cannot take the chance of changing any existing entries without positive evidence that it is safe to do so. OK. Then we still need something more than the new TEST_CAPACITY flag trying to read the last reported block to see if the block exists or not. In cases marked as FIX_CAPACITY we ought to see if an existing partition ends in the last reported block -- if it doesn't then we can truncate the drive and no partition gets truncated, but if it does then maybe we should consider changing the device's flag to TEST_CAPACITY. > > In drivers/scsi/sd.c, fix_capacity always causes a decrement but guess_capacity guesses an even number. >> >> So one thing to do for the Prolific bridge in unusual_devs.h is to use US_FL_CAPACITY_HEURISTICS instead of US_FL_FIX_CAPACITY. > > Not all disks have an even number of blocks. That heuristic really isn't a very good one -- its only benefit is that it works okay for the one case where it is currently used. If you do mean disks, then we can improve that heuristic. Forget about the 126 that I mentioned last time, but go with the 63 because we know why that factor is very common in drives that had physical 512 byte sectors. For drives being made these days with physical 4096 byte sectors, obviously the number of logical 512 byte sectors is going to be even just as it is with the one device that presently has the HEURISTICS flag. If you mean other USB devices that emulate disks, then of course there's a wider range of possibilities. The ATA identification might assert any number of emulated sectors per emulated track, etc. And even when the device states its correct number of LBA blocks (not having been altered by fraudsters to sell a fake high capacity device in eBay), the vendor might have preformatted it with a partition extending past the end of the device. So yeah, I have no suggestion for devices other than actual disks being connected through USB to [S]ATA bridges. >> I also think that if the reported capacity is a multiple of 63 then it is very likely to be accurate and should not be decremented. Furthermore if the capacity is a multiple of 126 (i.e. even as in the current heuristic, and a multiple of 63) then US_FL_FIX_CAPACITY is almost certainly wrong. Of course that 63 is artificial but it is very common and the reason is well known. > > You seem to be ignoring the fact that we aren't just talking about USB-(S)ATA bridges. I was but you weren't. For other kinds of devices I have no suggestions, as mentioned above. -- 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
