Paul Ripke writes:
> Just worked out a problem that has been bugging me for a while now,
> (thanks, Manuel!) where /etc/rc.d/raidframeparity fails at startup,
> caused by some turkey [me] deciding to use the 'd' slice of raid
> devices for filesystems... So what I'm now wondering is why
> raidctl(8) shouldn't use raw devices by default, which would stop
> the above failure.

If we did that, then things like fsck would be unhappy because it can't 
check the raw device while parity is being rebuilt. (Or parity 
wouldn't get checked because the device is being fsck'ed..)  You also 
wouldn't be able to newfs the set using the raw device while rebuilding 
parity.  You also wouldn't be able to do a full 'dump' at the same time 
as a parity rebuild. 

> Scanning through the source, I believe it is all ioctls, no reads
> or writes are made to the device.
> 
> Thoughts?

He man-page hints that 'raid0' maps to '/dev/rraid0d', so it probably 
should be changed (or the man-page fixed):

     The device used by raidctl is specified by dev.  dev may be either the
     full name of the device, e.g., /dev/rraid0d, for the i386 architecture,
     or /dev/rraid0c for many others, or just simply raid0 (for
     /dev/rraid0[cd]).  

More importantly, however, the man-page also says:

     It is recommended that the partitions used to repre-
     sent the RAID device are not used for file systems.

There are 8-16 other partitions available.... It's not that hard 
to just "pick a different one". ;) :)

A "correct" fix might be to have just /dev/raid0 , and use that for 
control of raid0.  But we don't have that (yet?), and the workaround 
is fairly trivial.

Later...

Greg Oster