Paul Ripke writes:
> 
> On Friday, Feb 13, 2004, at 00:31 Australia/Sydney, Greg Oster wrote:
> 
> > 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.
> 
> Um - sure? 

Apparently not completely.. :)  And emperical evidence always beats theory :)

> The only raw device that implements any locking that I'm
> aware of, is tape devices. Multiple access to sequential media
> doesn't make sense. I just tried a few dd's reading/writing to the same
> /dev/rvnd0d without any hassles. I thought that was one of the features
> of raw/character devices.
> 
> Taking the test further, I've just run a newfs while "raidctl -vR" was
> running against the same raw device - all worked fine, as I thought it
> should. fstat reports it open multiple times:
> ksh$ fstat /dev/rraid0d
> USER     CMD          PID   FD MOUNT       INUM MODE         SZ|DV R/W 
> NAME
> root     newfs      22425    3 /           7481 crw-r-----  rraid0d r   
> /dev/rraid0d
> root     newfs      22425    4 /           7481 crw-r-----  rraid0d w   
> /dev/rraid0d
> root     raidctl    23133    3 /           7481 crw-r-----  rraid0d rw  
> /dev/rraid0d
>
> The only question in my mind, is what happens at securelevel >= 1...

There are other issues there, including disklabelling bits, I 
think... 

So long as the change doesn't make anything *worse*, I have no 
problem making it... (It's just a matter of changing a '1' to a '0' 
in the opendisk() line in raidctl.c, I think...)

Later...

Greg Oster