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

On Apr 7, 2005, at 2:13 PM, Poul-Henning Kamp wrote:

> First of all, there are tools which do not do the right thing.
> Amongst these are bsdlabel, fdisk, boot0cfg and sysinstall.  Most
> of them do something right but none of them gets everything right.

One can argue that these tools weren't broken before GEOM came along
and that the implementation of GEOM in FreeBSD could have been done
slightly better? (see also below)

> Let me try to explain what should happen using the deletion of a
> MBR partition as example:
>
> If the disk has an MBR which defines three partitions and one of
> these are open, then the MBR cannot be written to without informing
> the GEOM_MBR instance which implements the contents of that MBR.

Questionable. What about the following reasoning:

The partition table on a disk is there to help the firmware and OS
to identify the kinds of file systems on that disk and their bounds.
Once the OS has been loaded and has obtained all the information it
cares about, the partition table is not needed anymore. Its existence
has become irrelevant. Removal of the partitition table does not in
any way invalidate the file systems that are on that disk, nor make
them inaccessible to the CURRENTLY RUNNING OS. It is only when the
partitions are to be found again across a reboot that the partition
table needs to be there and needs to be valid.

So, one can argue that the removal of a MBR does not change a damn
thing to the file systems currently mounted by the OS and one can
also argue that replacing a MBR with a different table, say a GPT,
that otherwise encodes the exact same information is something that
can be done regardless and without having to invalidate any in-core
information about partitions or force a complete refresh of it.

Even if a replacement partition table encodes a completely different
layout, does it not have to be a problem. The OS just needs to ignore
the partition table.

Thus:
Is it actually the right behaviour to invalidate the OS's notion of
disk partitions whenever the on-disk tables are changed or removed
and if so does that hold in all cases?

> The correct way to do that is to use the g_ctl() api because what
> is needed is an out-of-band mechanism to tell that we want to loose
> one of the partitions.

Such mechanism would be needed only to inform the OS that it should
forget about partitions it currently knows about (whether mounted or
not).

> 1. Find out which partition format we migrate to instead of BSDlabel
>    which runs out of steam around 2TB.  GPT has been proposed but
>    seems to be a rather dead end with Itanic sinking fast.

Itanium is not sinking fast. It's submerged, but holding for now. The
Open Source community simply isn't the audience for it yet and may very
well never be. This doesn't mean that there isn't an audience at all.
That aside: whether GPT will find its way to the PC is of course a
different story -- independent of whether the floatation devices are
pulled from under the Itanium architecture.

> Anybody who expect me to do all of this singlehandedly can take a peek
> here http://people.freebsd.org/%7Epeter/srcsys.window.txt and go stick
> their head in a bucket of cold water before telling me I have to work
> harder.

A yes, the classic trick of showing quantity when quality is questioned.

The bottomline: You tell a nice story and people tend to believe it if
you repeat it often enough or tell it assertively, but some questions 
remain
unanswered and so far the problems have remained unsolved. What I fail 
to
see is the proverbial "let's take a step back and look at it again from 
a
distance" attitude from you. Instead everybody else's got it wrong or is
missing bits and pieces from the puzzle. Fine, that's certainly 
possible,
but you're not making a good case for it and I remain unconvinced 
(FWIW).

So, maybe it's time to step back and take a look at it again. Define the
problems that have been raised, describe the cause (real or artificial) 
and
identify possible solutions, not just yours, and build consensus for the
best solution. Chances are that you actually get other people to help 
out
implementing the solution.

Just some food for thought...

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