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

On Fri, Apr 08, 2005 at 11:14:39AM +0400, Andrey Chernov wrote:
> On Thu, Apr 07, 2005 at 11:51:03PM -0700, Marcel Moolenaar wrote:
> > >F.e. one can temporary remove whole BSD partition for other OS better
> > >install, then re-create it again inside other OS.
> > 
> > I don't see how this is illegal. It's exactly the thing you don't want
> > to prevent for no good reason. It's a dangerous operation if you don't
> > know what you're doing but other than that can be a real handy feature.
> 
> I mean it becomes illegal when synced from on-disk to in-core - whole 
> working space disappearse. This is example why on-disk->in-core sync is 
> dangerous while in-core->on-disk is always safe.

Slow down, breath but most of all: think. You're not making much
sense. Compare both by applying the same change to both of them.
So, let's remove a BSD partition and for the heck of it, the one
containing the root file system:

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

The same applies to any and all changes.

> > But if a file system goes beyond the boundaries of a partition, you
> > don't need to increase the partition to get to the files. They were
> > written there despite the partition boundaries. Not to mention that
> > you can just read the adjacent partition to read the raw sectors.
> > No, your example isn't a good one.
> 
> Oh, this is real life example. And I mean FAT32 or NTFS (I don't remember 
> right now, one year passed) as a filesystem, not UFS. And I mean not 
> recover files goes beyound (there just was incorrect sector numbers, not 
> data written) but old files. The problem was that it simple not mounted by 
> Windows without such partition surgery. "Unmountable boot volume".

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
whatever you write to a partition, it will not cross its bounds?
I mean, if an OS is writing to a file system and is messed up
enough to completely go out of bounds then the data in the adjacent
partitions is already corrupted *or* there partition was surrounded
by free space. In the second case you don't have a proble, but in
the first case you might as well back up the adjacent partitions
and nuke them, because they have already been corrupted. You need
to do a lot more surgery than you can probably handle with existing
tools.

> > Why would you ever allow a partition table to contain overlapping 
> > partitions?
> 
> 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?

> > but never in the on-disk table by itself or in the in-core data by 
> > itself.
> > Right?
> 
> Not quite right. I want inconsistencies in on-disk table (with warnings 
> and (Y/N) confirmations etc.) because of surgery. But not in the in-core 
> table, because it is live running and could lead only to more chaos.

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.

Interesting...

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net