READ_CAPACITY_OFFBY1 [was: Re: usb/umass, devfs: this sucks]

[Henrik Gulbrandsen]

I'm dropping the stable list and continuing discussion on the USB list.

On Wed, 2007-12-26 at 11:48 -0700, M. Warner Losh wrote:
> The patch in [usb/78984] is wrong.  There are devices that are an odd
> number of sectors.  This is one of the places where the obvious patch
> isn't necessarily right.

On Wed, 2007-12-26 at 17:45 -0700, M. Warner Losh wrote:
> There's already a quirk for this problem that has been applied to the
> few devices that it affects.

That would be the new READ_CAPACITY_OFFBY1, which you checked in about
five months after my patch submission :-)

> Maybe we need to add one more to the list?  There was also talk of
> forcing a read to the last sector if the sector count was odd, but it
> never got past talk.

Well, there are at least three ways of handling this, but none of them
seems particularly good to me. It all boils down to a trade-off:

a) Using the quirk flag. This is the obvious solution, now when it has
   been added to the umass.c file. The problem with quirks in general
   is highlighted by your check-in comment: "...there are a host of
   other devices with this issue, including iPods and some popular
   cameras". Each of these will be separately debugged and added to
   the list, and since the link between cause and effect can be less
   than obvious in this case, that can take hours of work per device.

b) Reading from the last sector. This is an interesting solution, but
   worries me, because that sector will technically be out-of-range in
   the devices that we're interested in. If they can't get the sector
   count right, how will they handle a read from an invalid sector?
   I'm not a bit surprised if there are devices out there that would
   block indefinitely, convert the read to a write in the first sector
   and corrupt the file system, or generally burn the barn...

c) Using heuristics. This is what I did when I assumed that there should
   typically be an even number of sectors. While that is obviously a bit
   too optimistic, perhaps there are other sufficiently good algorithms
   for detecting the incorrect cases with a negligible number of false
   positives. It may be due to a lack of imagination, but I find it hard
   to think of any reason why somebody would put exactly 256001 512-byte
   sectors on a umass device, unless that's an off-by-one error in itself.

For my own personal use, solution (a) is good enough, but I'd prefer a
more general solution, so we can use scarce developer time in a more
useful way than for identifying this quirk over and over again.

/Henrik