On Tue, 7 Dec 2010, Bruce Cran wrote:
On Tue, 07 Dec 2010 23:54:17 +0200
Andriy Gapon <a...@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
anything.
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
are supported.
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
"supported"/nothing.
Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
