On Fri, 27 Apr 2012, Norman Diamond wrote: > > Let's just not worry about it.� It seems pretty clear that the patches > > will fix your immediate problem. > > Only partly, because an odd multiple of 63 is possible. Look, I didn't say the changes would help with every possible disk. Just that they would fix your immediate problem, i.e., the problem with your current disk. > > What about a device that has 6362 sectors but reports 6363?� Then your > > test would fail to decrement the value when we do want to. > > But we can't distinguish two versions of the device, one where 6363 > is correct and one where 6363 is wrong. I prefer to take the > device's word for it unless we know for sure that it is wrong. > TEST_CAPACITY would still be a good idea. FIX_CAPACITY (where we > know for sure that the device is wrong) will not suffer from this > ambiguity and will always get a decrement. That's the whole point of CAPACITY_HEURISTICS -- we have two versions of the device, of which one is buggy and the other isn't, and we can't tell them apart. If we preferred to take the device's word for it whenever we didn't know for sure, there would be no need for CAPACITY_HEURISTICS at all. For example, consider all those cameras sold by Nikon, Pentax, and so on. They probably all used Symbian's firmware, which some years ago had the capacity bug. Maybe the firmware has been fixed since then; I don't know. But under the reasonable assumption that the SD/CF/whatever memories used in these cameras will always have an even number of blocks, the existing CAPACITY_HEURISTICS solution is appropriate. > > Anyway, why do you want to test for n % 63 != 0?� You have no > > justification for decrementing the block count if the result would > > not be divisible by 63. > > I sure do. You know as well as I do that for decades a lot of ATA > disks reported capacities that were multiples of 63 and they had a > reason for it. ? That makes no sense. Go back and reread what I wrote. In particular, I was asking why you changed the test from (n % 63 == 1) to (n % 63 != 0). You know that for decades, ATA disks have reported capacities that were multiples of 63. So if a drive reports a capacity that is 5 larger than a multiple of 63, why would you want to decrement the value? The result still would not be a multiple of 63. Didn't you say that you preferred to take the device's word for it? > > Bear in mind that if anybody reports a problem caused by the new > > "divisible by 63" criterion, we will have to revert the changed test > > (the updated message could remain, since it doesn't affect > > functionality). > > Mostly I agree. But if reversion causes a different known problem to > be reinstated, then TEST_CAPACITY is really needed. The same caveat applies to TEST_CAPACITY. Also, the amount of effort required to write the TEST_CAPACITY code and get it accepted into the kernel would be non-trivial. I prefer not to do it unless it turns out to be clearly necessary. Alan Stern -- 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
