Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Apr 2005 03:49:27 +0400
From:      Andrey Chernov <ache@nagual.pp.ru>
To:        Marcel Moolenaar <marcel@xcllnt.net>
Cc:        current@FreeBSD.ORG
Subject:   Re: GEOM architecture and the (lack of) need for foot-shooting
Message-ID:  <20050408234927.GD37182@nagual.pp.ru>
In-Reply-To: <20050408223335.GA11503@ns1.xcllnt.net>
References:  <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> <20050408223335.GA11503@ns1.xcllnt.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 08, 2005 at 03:33:35PM -0700, Marcel Moolenaar wrote:
> > 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.

Saying "automatic or unexpected or by mistake" I describe non-standard 
error situation which may happens. In standard normal situation no 
unprovoked in-core->on-disk sync should happens in my variant, i.e. when 
admin don't want it.

> Hence, I argue that you edit the on-disk data only and control when
> and how the change should become effective. 

In my variant any on-disk data changes will become effective only on the 
next reboot, unless admin change his mind and intentionaly do 
in-core->on-disk sync, i.e. intentionaly backing out his own on-disk 
changes.

> Ok. I can agree to that. What I don't agree to is that invalid
> partition tables (e.g. partition tables that define overlapping

If you agree, why you specifically disallow invalid changes which may have 
f.e. special meaning of temorary recovery? See example of (1) & (2) 
partitions below.

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

In-core editing should reject any invalid changes conflicting with already 
open partitions including invalid changes of already open partitions by 
themselfs. On-disk editing should not. I.e. on-disk editing should make no 
assumptions of what partition table must be, but in-core editing have 
assumption that we have live running consisten system. Using that 
assumption in-core editing can do better checking.

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

Advantage of on-disk editing is that it is delayed until next reboot, 
while in-core editing is not delayed.

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

The point is minimal number of actions required. If I have partition (1) 
which is good and partition (2) which needs surgery, in your variant you 
need to change (1) & (2) first, then restore (1) & (2). In my variant you 
need to change only (2), then restore only (2).

> 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?

Yes.

> 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?

Why duplicate functionality, i.e. create separate tools set which does the 
same but only unrestricted? In such way you'll constantly need to keep 
both copies of utility in sync, more support required, instead of having 
one toolset, perhaps controlled with different options.

> 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).

1) See about in-core and on-disk safety differences above. ("Assumptions" 
paragraph).

2) Why in-core editing is needed: live example. Imagine you have disk with 
some OS installed with swapfile placed first and you know its size. Lets 
assume you temporary needs some file space. You can edit in-core table of 
that disk, putting partition just inside that swapfile space range. Then 
you can in-core label, newfs swapfile itself, put some files there for 
what they temporary purpose was and then reboot without initiating 
in-core/on-disk sync, of course. _Nothing_ will be written to on-disk 
partition/label in my variant, so any existen data there will be 
untouched.

-- 
http://ache.pp.ru/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050408234927.GD37182>