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

[Eric Anderson]

On 02/28/07 04:55, M. Warner Losh wrote:
> 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.


I think the trick is for it to read the last sector only on umass 
devices that have odd number of sectors.  That should reduce the 
warnings, and reduce the checks down to only the subset that probably 
would have the problem anyway.  That would nearly eliminate any other 
side issues or warnings.


> : >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
> _______________________________________________
> cvs-src at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/cvs-src
> To unsubscribe, send any mail to "cvs-src-unsubscribe at freebsd.org"