cvs commit: src/sys/dev/usb umass.c

[M. Warner Losh]

In message: <43716.1172659622 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: In message <20070228.033055.-135505832.imp at bsdimp.com>, "M. Warner Losh" writes
: :
: 
: >Others have observed that the number of sectors on a disk should be
: >even.  Therefore if maxsectors returned is even, it implies an odd
: >number of sectors and should be adjusted.
: 
: Hmm, although generally true for present day disks, I don't think
: it is universal enough that I would want to rely solely on it.

Google just showed me there are at least two real scsi disks with an
odd number of sectors.  It is a report about how Linux can't read the
last sector of those disks and notes in passing that FreeBSD 4.4
can...

It might be saner to just do this in the umass layer (eg, always
adjust there if maxsectors is even) rather than rely on a quirk.

: >number of sectors and should be adjusted.  That might be an even
: >easier path to follow...  I'm never sure when one can schedule
: >additional I/O inside of cam...
: 
: Neither am I.
: 
: Thinking about it, geom_disk might be a better place for it anyway.
: 
: That way we could postpone announcment of the disk to GEOM tasting
: until we know it can actually answer a request.   Spin-up and other
: long delays will not affect the system nearly as hard as they can
: today.
: 
: Early on I thought about a mandatory "read first & last sector"
: check for all providers created in geom, but dropped it due to the
: excessive shake, rattle and roll of big diskfarms and complex
: layouts.  But it might be a good idea to add it in a reduced form
: applied to all providers which come in at rank==1 (that way we
: would not do it for partitions, slices, mirrors etc).

I'm not entirely sure that's the right place for it either.  But the
invariant does seem sane.  The tasting code seems to already be
reading it anyway (which is how I noticed the problem recently that
I'd missed when I used this device on 4.x systems), so I'm not sure
how much overhead there would really be...

Warner