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? 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...

Cheers,
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams