On 02/28/07 04:55, M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: In message <[EMAIL PROTECTED]>, "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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-src
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
