Re: GEOM architecture and the (lack of) need for foot-shooting

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_at_xcllnt.net