From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 04:00:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 685C516A4CE for ; Fri, 8 Apr 2005 04:00:57 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9611943D31 for ; Fri, 8 Apr 2005 04:00:56 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j3840ZZ0035138; Fri, 8 Apr 2005 00:00:35 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j3840ZqH035137; Fri, 8 Apr 2005 00:00:35 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 8 Apr 2005 00:00:35 -0400 From: David Schultz To: Poul-Henning Kamp Message-ID: <20050408040035.GA34844@VARK.MIT.EDU> Mail-Followup-To: Poul-Henning Kamp , current@freebsd.org References: <20331.1112908380@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20331.1112908380@critter.freebsd.dk> cc: current@FreeBSD.ORG Subject: Re: GEOM architecture and the (lack of) need for foot-shooting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2005 04:00:57 -0000 On Thu, Apr 07, 2005, Poul-Henning Kamp wrote: > First of all, there are tools which do not do the right thing. > Amongst these are bsdlabel, fdisk, boot0cfg and sysinstall. Most > of them do something right but none of them gets everything right. [...] > The correct way to do that is to use the g_ctl() api because what > is needed is an out-of-band mechanism to tell that we want to loose > one of the partitions. > > g_ctl() has not been fully implemented in all classes yet, and > therefore what we currently do is open one of the partitions and > issue an ioctl which hits the GEOM_MBR instance. > > This worked fine until recently where it was discovered that one > could issue ioctls which did "write like" stuff on a filedescriptor > open only for read. This is pretty counter to what people exepect > and we fixed it. > > The problem with that is that there may not be any partition we can > open for write, they may all be opened by something else (mounted) > and therefore our attempt to open will fail. Thanks for the nice description of what needs to be done, and for taking a constructive attitude towards addressing these problems. So I don't have time to implement an API for disk partition layout changes. But before I read your message, I was looking into getting sysinstall to issue a DIOCSMBR ioctl to the disk instead of trying to write it directly. Would that suffice to allow users to safely modify their partition tables, while preserving the anti-foot-shooting mechanism? Of course, when someone has time to implement a g_ctl() to do this as you suggest, it would be easy to adapt sysinstall at that time. > Now, why havn't you finished GEOM ? I hear. > > Well, many reasons. > > For one thing I wanted to see how it panned out in all sorts of > ways before I went any further, it is important to stop up every > so often and see if the direction is still sound. > > Second, there was a lot of talk about sysinstallNG at the time and > I thought that would be a great time to revise the entire > userland-edit-disk-layout thing. > > Third, I needed a break from it. FWIW, my complaint was not about what you did or didn't manage to accomplish single-handedly. My complaint was that you turned on the anti-footshooting knob by default before userland was ready for it. > 1. Find out which partition format we migrate to instead of BSDlabel > which runs out of steam around 2TB. GPT has been proposed but > seems to be a rather dead end with Itanic sinking fast. Regardless of what happens to IA-64 and EFI, GPTs probably aren't going away. Within a few years, Intel and Microsoft will be forced to address the 2TB limit for run-of-the-mill desktops, and I really can't see them inventing yet another format. But those are just my two cents; you're right that this should be discussed further.