READ_CAPACITY_OFFBY1 [was: Re: usb/umass, devfs: this sucks]
henrik at gulbra.net
Thu Dec 27 11:14:43 PST 2007
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.
More information about the freebsd-usb