We're running Veritos and Online: Disk Suite from Sun here at UCSC.  
Veritos uses the technique Justin describes of keeping its configuration
information strewn about on private areas of the disks it administers.
Online: Disksuite keeps it's configuration information in replicated text
files on non-striped or concatinated volumes on the machine.  Neither
package, as far as I'm aware, allows you to mirror or stripe or concatinate
/ or /usr.
	From my perspective as an administrator of systems which use both types 
of virtual disk drivers, I have to say that I like the NetBSD way of
keeping the configuration file in a flat text file much better.  Veritos is
powerful, but it doesn't auto-recover from failed disks, and it is very
hard to manage its configuration information precisely because it is stored
on distributed areas of disks which are unreachable by mere mortals living
on FFS filesystems.  We have over 120 spindles (120GB) being controlled by
Veritos.  In order to construct a reasonable description of how all those
disks are layed out, as well as one that can be used to repair that layout
after a disk failure, one needs to run five  (5) or six(6) different tools
to verify that one has written down all the correct information.  Even
then, it is very easy for some small piece to get out of sync, and thereby
wipe out the validity of all that note paper.
	Online: Disk Suite, on the other hand, which we're using to manage a much 
smaller farm of disks, is a joy to manage over long periods of time because
the same configuration file that the machine uses to keep track of its
configurations is the one that one can print out and save for emergency
backup operations.  If you want to make a change, simply edit the
configuration file and run the appropriate parser to import that change
into memory.  If you have a number of administrators looking after the
system, simply put the configuration file under RCS and thereby obtain a
history of what is going on on your system. 

	While I like the theoretical benefits of having auto-configuring virtual
disk drivers, I have not seen that functionality work reliably on so-called
"industrial strength" systems.  Instead, the complexity and opaqueness of
the system has cost us a lot of extra money, both in general maintenance
terms and in times of failures.

	I would be strongly opposed to a CCD which did not use a text-file based
configuration scheme, and I am more than willing to give up striping and
concatinating the root filesystem in order to meet that goal.  If I only
have to roll one backup tape for a system of over 20 gigabytes, and can be
sure that that backup tape gives me the full ability to restore all of the
configuration information on the system, I'm a happy camper indeed!
-Brian

On Oct 1,  9:53am, "Justin T. Gibbs" wrote:
} Subject: Re: VPS mailing list, BSD interest?
} > > For instance, why can't I have my root-partition striped ?
} >
} >I think a better question is "why would I _want_ my root partition striped?"
} >:-)
} >
} >(The real answer to your question is "Becuse then you've added unnecessary
} >clutter to the ccd configuration code to deal with both statically-
} >and synamically-configured ccds".  In my mind, saying that your
} >MUST WORK AT ALL COSTS fileystem isn't allowed to be striped is an
} >acceptable trade-off :-)
} 
} Actually, I don't think it is.  CCD should be relying on information stored
} in a private area of the disk to determine what stripe sets what partitions
} belong to, etc.  This is how all of the industrial strength filesystem VM
} systems work.  When you open the partition, you see it has a CCD block 
} on it, and then pass it on to CCD informing it of the dev that the block
} came from.  The upside to this is that you can re-arange your disks (even
} put them on different controllers) and the system still finds your array
} and makes it work.  Having my root FS on a RAID 5 device makes it
} more robust than having it on a single disk. This is more than enough
} justification for allowing you to do this.
} 
} >Jason R. Thorpe                                       thorpej@nas.nasa.gov
} >NASA Ames Research Center                               Home: 408.866.1912
} >NAS: M/S 258-6                                          Work: 415.604.0935
} >Moffett Field, CA 94035                                Pager: 415.428.6939
} 
} --
} Justin T. Gibbs
} ===========================================
}   FreeBSD: Turning PCs into workstations
} ===========================================
>-- End of excerpt from "Justin T. Gibbs"