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

On Apr 7, 2005, at 11:31 PM, Andrey Chernov wrote:

> On Thu, Apr 07, 2005 at 11:18:17PM -0700, Marcel Moolenaar wrote:
>>> It bring some problems like illegal on-disk modification synced to
>>> in-core.
>>
>> Q: what would you consider illegal on-disk modifications?
>
> 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.

>>> Since on-disk editing is not controlled (and should not be), it
>>> may overlap or be incorrect in some other way.
>>
>> Q: why is on-disk editing not controlled and why shouldn't it be?
>
> There was a cases when filesystem is damaged, sectors goes off 
> partition
> limits, etc. There must be temporary way to fix - to write bigger
> (overlap) partition, grab needed files, then restore correct one.

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.

>>> But, if you edit in-core
>>> partition instead, as I suggest, you can do all sorts of checking and
>>> safety, easily excluding overlaps, etc.
>>
>> I can't say I buy into that. I don't see how in-core editing can be
>> better
>> checked than on-disk editing. Can you explain?
>
> In-core editing always suppose currently running correct partition 
> table.
> It must not allow to add, say, overlaping partition entry. On-disk 
> editing
> should allow to write incorrect partition table for temporary disk 
> surgery
> purposes.

Why would you ever allow a partition table to contain overlapping 
partitions?
Inconsistencies (i.e. overlaps) can exist between the on-disk and 
in-core data,
but never in the on-disk table by itself or in the in-core data by 
itself.
Right?

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