Date: Tue, 7 Dec 2010 23:06:24 +0000 From: Bruce Cran <bruce@cran.org.uk> To: Andriy Gapon <avg@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r216269 - head/sys/geom/part Message-ID: <20101207230624.7b7a83d3@core.draftnet> In-Reply-To: <4CFEAD09.30904@freebsd.org> References: <201012072046.oB7KkB4L079555@svn.freebsd.org> <4CFEAD09.30904@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 07 Dec 2010 23:54:17 +0200 Andriy Gapon <avg@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. -- Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101207230624.7b7a83d3>