Subject: Re: wedges vs. not-quite-wedges, was > 1T filesystems, disklabels, etc
To: Bill Studenmund <wrstuden@netbsd.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 12/19/2002 17:38:00
In message <Pine.NEB.4.33.0212191700480.9004-100000@vespasia.home-net.internetc
onnect.net>Bill Studenmund writes
>On Thu, 19 Dec 2002, Jonathan Stone wrote:

>I'm sorry, I am NOT proposing a subset of an LVM.

... seems to me that's exactly what you are proposing.  The subset-ness
is in whats managed (PVs, not LVs) rather than the functionality.
Sorry if I was unclear.

>I am proposing extending our partitioning methodology to support
>partitions coming from different partitioning schemes.
>
>While I'd love for us to have an LVM, and I think we should, I think the
>logical volumes of an LVM are different beasties from partitions, and as
>such neither the partitioning stuff I'm describing nor wedges will do for
>them.

OK, on that we agree.


>At boot, we itterate over all disks in the system. We read them for
>different disklabel types, and find partitions. We add them to a struct
>diskpart (a new disklabel-replacing structure). When we have found
>everything (or found 255 user ones), we shove the diskpart into the
>kernel.

Sorry, but that doesn't answer the question.  Which parts of ``at
boot'' are in the kernel, and which are done in usespace as we're
going multi-user? (Yes, I care).

>We then listen for disk-insert events. When a disk is inserted, we read it
>for partitions as above. [...]

Uh, *how*, exactly? What are the failure scenarios? What are the race
conditions? What security holes do we expose ourselves to?
And how do we get notified of disk events?

Yes, we have kqueue. Do we have disk-insertion events?  I can't see
them, Frank suggests maybe we need an event-routing daemon.  My source
tree is a few days old, but the only kqueue support I found in a quick
look is for changers; iirc ch(4) overlays read operations in ways I'd
rather not, for disks.  I submit that it's not entirely clear how this
will work.

As I think I've said more than once now, I think the _hard_ problems
lie elsewhere: in specifyin how the 256-diskparts-per-disk are carved
up in a way that gives stable numbering, stable /dev entries, stable
/etc/fstab entries, etc, when one OS on a multi-OS disk gets
repartitioned.

If we can solve _that_, it should be a SMOP to configure different
``label' format-reader as kernel option, for those who (for whatever
reason) just dont want to go the userspace route.