GEOM architecture and the (lack of) need for foot-shooting
Marcel Moolenaar
marcel at xcllnt.net
Thu Apr 7 23:51:06 PDT 2005
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
More information about the freebsd-current
mailing list