Re: recent changes prohibit vinum swap.

>>>>> "Robert" == Robert Watson <rwatson_at_freebsd.org> writes:

Robert> On Fri, 26 Sep 2003, David Gilbert wrote:

>> Recent changes to -CURRENT prohibit vinum swap:
>> 
>> [1:6:306]root_at_mu:~> swapon /dev/vinum/swapmu swapon:
>> /dev/vinum/swapmu: Operation not supported by device

Robert> In order to support swapping, Vinum will need to be modified
Robert> to use struct disk and the disk(9) API, rather than exposing
Robert> its storage devices directly via struct cdevsw and
Robert> make_dev(9).  I.e., Vinum probably needs to start approaching
Robert> things as "disks" rather than "devices", a distinction that's
Robert> becoming more mature in -CURRENT.

>> From a quick read of vinumconfig.c, I'm guessing this wouldn't be
>> hard to
Robert> implement.  Some subset of struct sd, struct plex, and struct
Robert> volume will need to start holding a struct disk instance which
Robert> would be passed to disk_create() instead of a call to
Robert> make_dev().  Much of the remainder will just consist of a bit
Robert> of tweaking to make Vinum extract its data from
bp-> bio_disk->d_drv1 instead of bp->b_dev, replacing the ioctl dev_t
Robert> argument with a disk argument, etc.

Is this something that someone can help me with quickly, or should I
downgrade the machine until it's been done?  Is there a quick hack to
make it work for now?  If I must downgrade, what date would be
appropriate?

Robert> I also noticed that the vinum commandline tool is a bit
Robert> devfs-unfriendly, or at least, it gets pretty verbose about
Robert> how all the files/directories it wants to create are already
Robert> present.  It could be that a test for devfs conditionally
Robert> causing a test for EEXIST would go a long way in muffling the
Robert> somewhat loud complaining :-).

Well... vinum is fragile in a whole bunch of ways.  vinum rm often
leaves things in an inconsistant state.  I almost always reboot now
after using it.  vinum rename doesn't change the devfs vinum directory
... which then also requires a reboot to correct.

Another thing that's very fragile is resetconfig.  It blanks memory,
but not disk.  It's often hard to get things running after that.  Many
times, I've had to resetconfig, reboot without loading vinum, dd to
blank the disk, reboot, load vinum and start again.

That all said, I see raidframe has been sucked in.  Are there plans
with that?

Dave.

-- 
============================================================================
|David Gilbert, Independent Contractor.       | Two things can only be     |
|Mail:       dave_at_daveg.ca                    |  equal if and only if they |
|http://daveg.ca                              |   are precisely opposite.  |
=========================================================GLO================