Date: Fri, 8 Apr 2005 15:33:35 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Andrey Chernov <ache@nagual.pp.ru>, Poul-Henning Kamp <phk@phk.freebsd.dk>, current@FreeBSD.ORG Subject: Re: GEOM architecture and the (lack of) need for foot-shooting Message-ID: <20050408223335.GA11503@ns1.xcllnt.net> In-Reply-To: <20050408210453.GA32421@nagual.pp.ru> References: <09c6072206df99be25e345b7e13354f5@xcllnt.net> <20050408050405.GA5203@nagual.pp.ru> <19f3c4e12937f581f7420bc841a11810@xcllnt.net> <20050408055144.GA6147@nagual.pp.ru> <b1fbaa6b2ea41e893ae1f3c94d49c2ee@xcllnt.net> <20050408063138.GA6884@nagual.pp.ru> <4fc54539e2b80a0718c8d21be862c379@xcllnt.net> <20050408071439.GA7431@nagual.pp.ru> <20050408191045.GA10743@ns1.xcllnt.net> <20050408210453.GA32421@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 09, 2005 at 01:04:53AM +0400, Andrey Chernov wrote: > On Fri, Apr 08, 2005 at 12:10:45PM -0700, Marcel Moolenaar wrote: > > o Editing the in-core data is an immediate show-stopper. You > > immediately pull the root file system from under the running > > OS. Not good, no matter what the failure mode. > > Yes. > > > o Editing the on-disk data is harmless as long as you don't > > sync in the in-core data with the disk. It's a showstopper > > when you do sync. The advantage is clear. You can have non- > > atomic operations that are dangerous, harmful or inconsistent > > when partly applied, but that may yield a harmless change > > when fully completed. > > Yes. > > > The same applies to any and all changes. > > I mainly mean on-disk->in-core sync moment in your scheme. If, by some > reason, automatic or unexpected or by mistake, such sync happens, it is > immediate show-stopper. The knack here is that synchronisation is as of yet not a defined operation. What does it mean? What does it entail? I certainly can implement synchronisation in terms of a reboot. In fact, it would be the (possibly) non-fatal implementation in the example I gave. How we synchronize and when is open for discussion and AFAICT has lots of potential for interesting solutions, including the boring reboot. If a reboot is what it takes, a reboot it'll have to be... > But in my scheme where only in-core->on-disk sync > exists, most unpleasant sytuation, if such sync will happens automatic or > unexpected or by mistake, was lost on-disk surgery changes, which is far > less painful. Yes, but also the least useful. Editing the in-core data behaves no different than editing the on-disk data followed by an immediate and unconditional sync. Since this is currently how GEOM works (in abstract at least), it wouldn't solve anything. Hence, I argue that you edit the on-disk data only and control when and how the change should become effective. This, I believe, is all it takes to address to issues that have been raised. > > I see. Do you think it's wise to design for broken file system > > implementations? Don't you think that it's fair to assume that > > It was just one real example which not worth to discuss in its particuar > details. Lets go to higher level of which this example should illustrate. > The higher level is: sometimes something happens which needs to make > artificial changes in the on-disk (not in-core) partition, disklabel or > boot, usually temporary in nature. Ok. I can agree to that. What I don't agree to is that invalid partition tables (e.g. partition tables that define overlapping partitions) are required. Thus: there's no need to allow changes to on-disk data that you wouldn't allow to in-core data. Ergo: the argument that in-core editing is more safe or can be better checked doesn't hold IMO. If you add to this the fact that in-core editing takes effect immediately (the root of the problems), I can not see what the advantage is to do it. > > > For surgery purposes. Consider this like fsdb(8). > > > > I look at it from a much more elementary point of view: if you > > do surgery that crosses partition boundaries, then you need to > > be doing raw disk access and no partition table is prohibiting > > you therein. Why then is there a need to change the partition > > table? > > Not all situations are so bad so only raw disk access can handle them, > some of them can be fixed with less pain using unrestricted standard > partition/disklabel/boot editing tools. Which means that you can solve it without creating invalid partition tables. You can always avoid overlapping partitions by shrinking one or removing it completely. The meta-data (i.e. the partition table) does not reflect reality anymore. There's no difference between slightly wrong and utterly wrong. Is it more work? Sure. Can it be automated? Definitely. Do we need it in our tools? See below. > > I see. I think this is another point on which we differ: you want > > to be able to edit the partition table to accomodate certain kinds > > of surgery. I think such surgery doesn't need support from the > > tools as it goes well beyond the functionality of partitioning. > > Before GEOM I was able to use hex editor to edit disk directly too (now > GEOM prevents even that). But editing those things with special tool is > far more convenient that manualy compute all offsets and find needed > bytes. Sure. I personally don't worry about that now. All I want to know is whether a certain approach would make certain things impossible, if it creates new problems and most importantly, whether it actually addresses the issues at hand. For most of the things I don't care about how it could or should be done, other than to find a single example that tells me that it's not impossible to do it. Eventually you find the "best" approach among the viable candidates and you go with it. Only in finding the best candidate do you want to look in more detail at how you can do certain things as it may be simpler in one approach than the other. > Old fdisk-like tools in many OSes was more admin-friendly because > not have new wave restrictions to prevent novices to do something wrong. > All strictness here is recent innovation which makes admin life harder. > For the sake of unknow newbies: Tom, Jerry, etc. Can it be that part of the problem is that many admins still think in terms of fdisk and as such find themselves blocked by those tools that don't work like fdisk? Or can it be that a need was created for a specialized tool, only to be used in special occasions by real men, not the mere sysadmins? My point is that your examples cover a space where Peter Norton used to fill the gap on MSDOS. Maybe that's the way to go? I don't know, but more importantly I don't have to. If the tool makes sure it creates valid partition tables, the kernel doesn't have to be involved in checking (it shouldn't anyway) and it's trivial to create a tool that allows you to create invalid partitions (whether controlled or not). I just don't see a need for it and as such reject some of your arguments your brought forth to explain/defend your statements. It doesn't mean that such a tool would not ultimately be handy. In short: I understand your examples. I just don't think they have any relevance to your argument that in-core editing is needed or that there's a difference between on-disk and in-core editing (safety-wise). > I suggest the compromise between this two methods: when the changes are > inconsistens, on-disk editing tool can complain as loudly and verbosily as > it can (warnings, confirmations, etc.) but not finally prevent > modification. Because human knows better, what machine needs. This is an easy compromise. A command-line option is all that's needed to change a tools behaviour from reject to complain (error to warning) or vice versa. I don't see anything prohibited either way so it doesn't affect the solution. Deal. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050408223335.GA11503>