Date: Mon, 27 Jan 2003 13:16:12 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: phk@freebsd.org Cc: Nate Lawson <nate@root.org>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sbin/disklabel disklabel.c Message-ID: <20030127211612.GA582@dhcp01.pn.xcllnt.net> In-Reply-To: <21754.1043667421@critter.freebsd.dk> References: <20030127104555.GA3050@dhcp01.pn.xcllnt.net> <21754.1043667421@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 27, 2003 at 12:37:01PM +0100, phk@freebsd.org wrote: > In message <20030127104555.GA3050@dhcp01.pn.xcllnt.net>, Marcel Moolenaar write > s: > > >Clearly this isn't getting anywhere and you also don't give any > >reason whatsoever why fixing geom is not an option. So, at this > >time I can only conclude that there are non-technical forces > >at work... this is where I step out of the discussion and into > >bed... > > First of all: The ratio of normal I/O requests to operations which > examine or modify partitioning meta-data is so staggering high that > it should be obvious that there is no sane reason to take even the > smallest performance hit in the normal I/O path to cater for meta-data > updates. And thats where it stops. You can call this "non-technical > forces" if you like, but that is not what I would choose to call > it. The problem of not pessimizing the common I/O when uncommon I/O is to be allowed does not automaticly yield the solution implemented with GEOM and also does not yield a single solution only. So, describing the problem does not rationalize, in any way, the alternative used with GEOM to address the problem. Consequently, you still haven't given any reason whatsoever why fixing geom is not an option. And so this too is not going anywhere. > Second, if you add a sysctl that allows you to write to /dev/ad0 > while it is being actively used, then you can update the on-disk > GPT tables, but you still need to notify the GPT module that a > change occured, and in doing so, you may present the GPT with a new > on-disk GPT table which would blow any number of already open and > mounted partitions out of the water. Good point. However it is a fundamental problem that exists no matter how you abstract partitioning. Disallowing updates does not make the problem go away nor does changing the mechanics of updating the meta- data cause the problem to change. The current behaviour of GEOM is pleasing in that when you change a configuration (whether that's adding a partition entry or configuring a memory disk) the effect is immediately visible under /dev and you can use the new disk/partition/slice right away. Not bad. As for the case where the configuration is changed in a destructive or conflicting way this can cause all sorts of problems. However, I think this is the uncommon of the cases. Partitition tables are only seldomly changed in a conflicting way on purpose. Hence the common case is a change in meta-data that is consistent with the current configuration. I agree that optimizing the common case at the cost of pessimizing the uncommon case is good and so GEOM does with I/O. However, this is not done for updating meta-data. GEOM at this time disallows updates (excluding the recently added hooks) because the meta-data may conflict with the correct configuration and as such favors the uncommon case and even makes the common case impossible. Only with the added ioctls is it possible to update the meta-data. For GPT this still yields a significant pessimization. > So: How do you intend to make that notification happen, and how > do you intend to handle the case where the new on-disk GPT table > would violate open partitions ? I intend to make it happen by telling you that ioctls are not the right way to update GPT and then to leave you alone so that you can figure it out. See also below. As for my thoughts on both subjects: notification: after having performed all reads and writes necessary to update the meta-data, a tool can optionally use a sysctl or an ioctl to tell GEOM to retaste. The optionality allows the system administrator to control whether GEOM should use the new table right away or not. This allows the SA to perform additional tasks while the kernel uses the old partitioning. These tasks can include a reboot. When the SA opts to retaste he/she is responsible for the consequences. 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. > Now, if you want to cooperate on trying to make a generically usable > interface for such operations, I'm all open for cooperation. Not so far. You have been telling me that you are working on the GPT issue (see this MLs archive). I now get the distinct impression that you have no plans whatsoever to finish the job you started. On another mailinglist you have let people believe that everything was cool and that you were not aware of any bugs and that you only had on or two loose ends to tie. Yet, I still cannot update the GPT and after I shot down your proposed kludges you ask me how *I* want to solve the problems? So ok, call me weird, but I don't call that cooperation at all. > PS: And trust me: I have only inflicted GEOM on you and the rest > of the FreeBSD crew in order to annoy you and to restrict your > possibilities and restrain the performance. Really: That's why. Ah, ok. I thought you were in denial, but deliberately implementing these flaws so much more sensible. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20030127211612.GA582>