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>