Date: Thu, 27 Dec 2007 21:15:16 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: Henrik Gulbrandsen <henrik@gulbra.net> Cc: freebsd-usb@freebsd.org Subject: Re: READ_CAPACITY_OFFBY1 [was: Re: usb/umass, devfs: this sucks] Message-ID: <20071227201515.GC31522@cicely12.cicely.de> In-Reply-To: <1198781185.1119.478.camel@Particle> References: <1198689316.1119.382.camel@Particle> <20071226.114812.1649771240.imp@bsdimp.com> <1198713403.1119.414.camel@Particle> <20071226.174523.1326317191.imp@bsdimp.com> <1198781185.1119.478.camel@Particle>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 27, 2007 at 07:46:25PM +0100, Henrik Gulbrandsen wrote: > 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. This is my cellphone with a 2GB micro-SD: da9 at umass-sim3 bus 3 target 0 lun 0 da9: < > Removable Direct Access SCSI-0 device da9: 1.000MB/s transfers da9: 1950MB (3994377 512 byte sectors: 255H 63S/T 248C) It offers not the complete media - it offers the slice as the whole media, so theoretically I can adjust the drive size by any number of blocks. And of course you shouldn't forget that umass can also be any kind of HDD attached to an USB converter. I assume part of the problem is that if the media is announced wrong noone has to care about it as long as all sectors can be read, which means that the driver shouldn't truncate to the media size and we don't partition the media ourself, which is most likely true for cameras and such, where most people let the camera partition the media. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071227201515.GC31522>