Date: Tue, 28 Jan 2003 09:11:52 +0100 From: phk@freebsd.org To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Nate Lawson <nate@root.org>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: Updating partition information [was: Re: cvs commit: src/sbin/disklabel disklabel.c] Message-ID: <32237.1043741512@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 27 Jan 2003 23:41:40 PST." <20030128074140.GA55074@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030128074140.GA55074@athlon.pn.xcllnt.net>, Marcel Moolenaar writ es: >On Tue, Jan 28, 2003 at 07:34:26AM +0100, phk@freebsd.org wrote: >> >> >violation: in the above scheme, the SA is is responsible for getting >> >his feet out of the way. Failure to do so results in undefined >> >behaviour, including but not limited to panics, corruption and a >> >wooden foot. >> >> Sorry, but no, that will not be the way it will work. > >Ok. 360 degree turn: > >What if we create an interface that's based on elementary operations >such as add, remove, reindex, move, change. An update of the meta- >data is then achieved by a sequence of these operations. Advantages >are: I hate to keep rejecting you, like this, but I actually have been down most of the roads before and failed to find an end. I tried this approach at one point and it fell short due to the weird and wonderous restrictions various label formats puts on their partitions: Some wants things to start at cylinder boundaries or be integral cylinders, or have absolute offsets encoded in C/H/S format, some want partitions to be in a specific order physically and in the table and so on. It may sound pretty generic but at the end of the day it just isn't. In the end, the only model I have found which makes some kind of overall sense is the one I have been moving fdisk and disklabel towards: userland program prepares byte-for-byte copy of metadata area on disk. If (if a class of our type is active) send byte-for-byte copy to that class. else write it in the disk partition ourselves. The class on receiving the byte-for-byte copy, will go through the same gyrations to validate and verify the data as if it had just found it on the disk only, this time taking into account which partitions are already open. If the new copy does not violate any of the class' sensibilities, it will go ahead and write it on disk and update its in-core copy (see geom_bsd.c:g_bsd_modify() for instance). This model puts the hard work in the userland program, and minimizes the kernel part, which IMO is a good thing. I can fully understand you opposition to using ioctl, but at this moment it is the simplest interface to use. If you look at the gyrations I had to go through to get 8k boot blocks sent to the BSD class, you will find it hard to not belive me when I say I want to find a cleaner way too. In some areas, this entire excercise is about undoing 10-15 year old mistakes and short-cuts, and sometimes you cannot go to the final solution but have to take a detour to get there. Finally, about cooperation: I can fully understand your impatience and frustration, but I also hope you appreciate just how big a load switching to GEOM actually is. It doesn't get any lighter by the requirement to keep the old code running in parallel and trying to do the SMPng thing at the same time. Only just today we have actually reached the milestone where GEOM surpasses the old code in functionality and where the old code can be sent down the river in an leaky boat. Now we can truly start to reap the benefits which GEOM promises. And I _really_ appreciate the fact that you went and did geom_gpt.c on your own, and I do appreciate all the help people have given me with GEOM stuff, many thanks guys! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32237.1043741512>