From owner-svn-src-all@FreeBSD.ORG Wed Jul 22 11:35:02 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 688E11065670 for ; Wed, 22 Jul 2009 11:35:02 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp03.sth.basefarm.net (ch-smtp03.sth.basefarm.net [80.76.149.214]) by mx1.freebsd.org (Postfix) with ESMTP id EC3598FC22 for ; Wed, 22 Jul 2009 11:35:01 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:50225 helo=falcon.midgard.homeip.net) by ch-smtp03.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MTZnv-00076C-AC for svn-src-all@freebsd.org; Wed, 22 Jul 2009 13:16:13 +0200 Received: (qmail 83408 invoked from network); 22 Jul 2009 13:16:09 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 22 Jul 2009 13:16:09 +0200 Received: (qmail 97564 invoked by uid 1001); 22 Jul 2009 13:16:08 +0200 Date: Wed, 22 Jul 2009 13:16:08 +0200 From: Erik Trulsson To: Alexander Motin Message-ID: <20090722111608.GA97528@owl.midgard.homeip.net> References: <200907220350.n6M3osaj030202@svn.freebsd.org> <4A66D0F4.4030108@FreeBSD.org> <4A66E9BE.2020603@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A66E9BE.2020603@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1MTZnv-00076C-AC. X-Scan-Signature: ch-smtp03.sth.basefarm.net 1MTZnv-00076C-AC 4b219592b5716b306ac81e3343a3dd3a Cc: Juli Mallett , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r195817 - head/usr.sbin/sysinstall X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 11:35:02 -0000 On Wed, Jul 22, 2009 at 01:28:14PM +0300, Alexander Motin wrote: > Juli Mallett wrote: > > On Wed, Jul 22, 2009 at 01:42, Alexander Motin wrote: > >> Colin Percival wrote: > >>> Remove the "dedicated disk mode" partitioning option from sysinstall, in > >>> both the disk partitioning screen (the 'F' key) and via install.cfg (the > >>> VAR_DEDICATED_DISK option). This functionality is currently broken in 8.x > >>> due to libdisk and geom generating different partition names; this commit > >>> merely acts to help steer users away from the breakage. > >> Is there any other way to not align FS block to the ugly legacy 63 > >> sectors per track boundary with sysinstall now? I think RAIDs won't be > >> happy. May be it would be better to fix it? > > > > If you're interested in fixing this issue, you might want to look at > > the need for compatibility names so that existing DD installs aren't > > broken, and so DD installs work as-is without correcting libdisk's > > expectations about slice/partition names for DD disks, which is pretty > > invasive, too. Not breaking new installs by not letting users install > > broken systems is the absolute bare minimum approach, and given the > > late date and the lack of movement on the kernel side, I've been > > advocating for it for a while. > > > > See this message and others in the thread for some background: > > > > http://lists.freebsd.org/pipermail/freebsd-geom/2009-June/003567.html > > Sorry, ENOTIME. I am not advocating DD mode, it is really a hack. Offset > 0 is just an easiest choice to align FS. Instead, I would really like > sysinstall to honor real disk geometry instead of fake one. "real disk geometry" ? How would sysinstall find that? Keep in mind that any disk geometry reported by disks is completely fake these days and is just an attempt to fit the total number of blocks into the limitations of the PC BIOS. E.g. AFAIK there are no disk in production today with more than 10 heads, and even that many is rare. The number of sectors/track is actually variable, with the outer tracks having more sectors/track than the inner ones. In short the whole notion of 'disk geometry' is mostly obsolete these days and ought to be avoided as far as possible. -- Erik Trulsson ertr1013@student.uu.se