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/Received on Fri Apr 08 2005 - 21:49:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC