From owner-freebsd-hackers  Wed Oct  2 07:04:58 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id HAA09465
          for hackers-outgoing; Wed, 2 Oct 1996 07:04:58 -0700 (PDT)
Received: from critter.tfs.com ([140.145.230.252])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA09458;
          Wed, 2 Oct 1996 07:04:53 -0700 (PDT)
Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id QAA03229; Wed, 2 Oct 1996 16:04:23 +0200 (MET DST)
To: matthew green <mrg@eterna.com.au>
cc: Darren Reed <avalon@coombs.anu.edu.au>, hackers@freebsd.org,
        tech-kern@netbsd.org, jrg@demon.net (James R Grinter),
        thorpej@nas.nasa.gov
Subject: Re: VPS mailing list, BSD interest? 
In-reply-to: Your message of "Wed, 02 Oct 1996 23:29:18 +1000."
             <199610021329.XAA26262@eterna.com.au> 
Date: Wed, 02 Oct 1996 16:04:23 +0200
Message-ID: <3227.844265063@critter.tfs.com>
From: Poul-Henning Kamp <phk@critter.tfs.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199610021329.XAA26262@eterna.com.au>, matthew green writes:

Well how about this:

	Filesystems and other users of block devices and their
	associated (simulated) character devices.
	-------------------------------------------------
	Geometry layer.
	-------------------------------------------------
	actual bdev drivers

In the geometry layer, you can knit any setup you want:

The stuff most people do now:

                top   top   top  top  top
                 |     |     |    |    |
                 +----------------------
        top top  BSD
        |   |    |
	----------
          FDISK
            |
          bdev


Or how about just mirroring:

        top  top  top  top
         |    |    |    |
         ----------------
               BSD
                |
              mirror
              |    |
             bdev bdev

Or some striping ?

        top  top  top  top
         |    |    |    |
         ----------------
               BSD
                |
              stripe
              |    |
             bdev bdev

You get the idea ?

For autoconfiguring I imagined all the various modules ordered according
to the "canonical level" they work on:

	3: stripe, mirror, raid5
	2: BSD
	1: BAD144
	0: FDISK

When we configure a bdev we first offer it to all the level "0"
modules in turn, if one of them recognizes something on the disk
it likes it configures itself on it.  If nothing in level "0",
then we try level "1" and so on.  If nobody recognizes it, we
assume that that's it and leave it at that.  (devices that take
several lower devices, must wait till they find all their children
until they can configure themselves upwards.  (This bit could even
be done in user-land if various corners are cut.)

If you want mirroring: go for it.
If you want lvm a'la AIX:  hey It's just another module.
If you want something else: same thing...

All the devices you see in the schemas above will be present in 
/dev, but once you open one of them as a bdev, anything above that
level will not be openable as a bdev.  This allows you to fsck the
copies of a mirror separately and stuff like that.

You want to be able to mount a disk that came from another machine ?
ok, write a module and tie it in...

Now, >that< would be general setup.  This is the idea that makes me
call CCD "a hack".

Poul-Henning

PS: It is obvious that your boot facility must be able to find your kernel,
but that is another issue I think, it should be a reason to cripple
the geometry management.

--
Poul-Henning Kamp           | phk@FreeBSD.ORG       FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk    Private mailbox.
whois: [PHK]                | phk@ref.tfs.com       TRW Financial Systems, Inc.
Future will arrive by its own means, progress not so.