svn commit: r216269 - head/sys/geom/part
brde at optusnet.com.au
Wed Dec 8 06:03:44 UTC 2010
On Tue, 7 Dec 2010, Bruce Cran wrote:
> On Tue, 07 Dec 2010 23:54:17 +0200
> Andriy Gapon <avg at freebsd.org> wrote:
>> You repeated that statement, so I am picking on you :-)
>> Can someone show me how/where exactly modern drives fakes CHS
>> geometry? Let me specifically ask that question about modern (S)ATA
>> drives directly connected to a system (controller).
>> My impression is at least since ATA-7 there is no mentioning of
>> anything CHS-related in the specification. The fact that we keep
>> reading and interpreting some historically defined bytes that are now
>> marked as unused/reserved doesn't mean that those bytes actually mean
> You're right: I last looked at the IDENTIFY data about 7 years ago when
> those fields were defined; now they're marked as "obsolete". I guess
> the fields are still defined to keep old tools happy. Both atacontrol
> and camcontrol are still reading the IDENTIFY data and outputting
> the CHS fields even on ATA-8 drives, which I guess they shouldn't be.
Utilities for reporting capabilities must report capabilities if they
Whether unsupported fields should be reported as integer 0's or in a
special format (e.g., not printing anything for unsupported sub-fields)
is another question. atacontrol is a bit too simple and inconsistent.
It prints CHS values unconditionally. Then it prints "CFA supported"
if CFA is supported, else nothing. Then it inconsistently prints "LBA
supported " if LBA is supported, else "LBA not supported ". Then it
prints the number of sectors supported by LBA, but under a different
condition. Then it prints many more things like it prints LBA, using
"supported/not supported" or, again inconsistently, "yes/no" instead of
More information about the svn-src-head