Jorgen Lundman writes:
> Greg Oster wrote:
> > If you're wanting to do pure concatentation of different-sized disks,
> > then you'll have to use ccd, since RAIDframe doesn't handle that...
> > If the disks are all the same, then using a RAID 0 w/ RAIDframe > should wo
> rk
> > just fine..
> > 
> 
> What ? really?  Is this something I should worry about? I have a 30gig
> partition on boot disk, 40gig disk, and a 45 gigs disk, they seemed to
> raid0 together beautifully, but haven't been used much yet. Will they
> fall over later on?

They won't fall over, but you'll be wasting space on the larger disks...
In this case, 5GB on the one disk, and 15GB on the other.. (It'll work just 
fine, if you're content in wasting 20GB of space :) )  One thing you could do 
here is to make 3 30GB partitions, and use those for 1 RAID set, and then 
use the other 5+15GB for something else... (e.g. you could do a RAID 1 set 
on 5GB, and then leave the other 10GB for 'temporary space' or something.)

> Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
> /dev/raid0e 102053179       27 96950493     0%    /disk01
> 
> START disks
> /dev/wd0f
> /dev/wd1e
> /dev/wd2e
> 
> 
> 
> 
> 
> While I'm on the subject, thinking of a simple way of doing on disk
> encryption (crypt filesystem) and RAID looked to be fairly promising. 
> Do all READ and WRITE requests go through one set of functions in it? 

Yup... but that's the same with the CCD driver, and it's much easier
to work with :)

> The rf_netbsdkintf.c file looks promising, it has raidread() and
> raidwrite() which both call raidstrategy().

You probably want to look at the CCD driver instead -- at least it's all
in one file (and one header file).  Depending on how fancy the encryption
is going to be, it'd probably be easier to use ccd as your starting point.

(e.g. you would 'configure' the encryption driver much like you might a ccd 
that only had a single component, and that encryption driver would then 
do the appropriate block munging before passing the block along to the 
lower level...  )

Later...

Greg Oster