Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Sep 2003 10:07:52 +0930
From:      Greg 'groggy' Lehey <grog@FreeBSD.org>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        David Gilbert <dgilbert@dclg.ca>
Subject:   Re: recent changes prohibit vinum swap.
Message-ID:  <20030927003752.GS16008@wantadilla.lemis.com>
In-Reply-To: <Pine.NEB.3.96L.1030926180831.59608A-100000@fledge.watson.org>
References:  <16244.40636.428865.644209@canoe.dclg.ca> <Pine.NEB.3.96L.1030926180831.59608A-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--xPLL5cPndR2UZ7Mw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Friday, 26 September 2003 at 18:38:48 -0400, Robert Watson wrote:
>
> On Fri, 26 Sep 2003, David Gilbert wrote:
>
>> Recent changes to -CURRENT prohibit vinum swap:
>>
>> [1:6:306]root@mu:~> swapon /dev/vinum/swapmu swapon: /dev/vinum/swapmu:
>> Operation not supported by device
>
> In order to support swapping, Vinum will need to be modified to use struct
> disk and the disk(9) API, rather than exposing its storage devices
> directly via struct cdevsw and make_dev(9).  I.e., Vinum probably needs to
> start approaching things as "disks" rather than "devices", a distinction
> that's becoming more mature in -CURRENT.
>
> From a quick read of vinumconfig.c, I'm guessing this wouldn't be hard to
> implement.  Some subset of struct sd, struct plex, and struct volume will
> need to start holding a struct disk instance which would be passed to
> disk_create() instead of a call to make_dev().  Much of the remainder will
> just consist of a bit of tweaking to make Vinum extract its data from
> bp->bio_disk->d_drv1 instead of bp->b_dev, replacing the ioctl dev_t
> argument with a disk argument, etc.

I'll take a look at this soon.  If somebody else wants to look first,
please let me know.  The introduction of GEOM means quite a shake-up
in the Vinum structure.

> I recently noticed that Vinum may be averse to blocksizes other than
> 512 bytes.

It shouldn't be.  There's never been any dependency on it.

> Or at least, I can get Vinum mirrors up and running on md devices
> backed to memory, but not to swap, and the usual reason for problems
> on that front is the 4k blocksize for swap-backed md devices.

I've had a number of problems with md devices.  This one may be that
Vinum is presenting a 512 byte block size upwards instead of the 4 kB
that it should be showing.  Again, I'll take a look.

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

I'm not sure I understand this.  Can you give me a concrete example?

Greg
--
See complete headers for address and phone numbers.
NOTE: Due to the currently active Microsoft-based worms, I am limiting
all incoming mail to 131,072 bytes.  This is enough for normal mail,
but not for large attachments.  Please send these as URLs.

--xPLL5cPndR2UZ7Mw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE/dNvgIubykFB6QiMRAoJgAJ9mFmRvvHv9IJm9OGhYxN1ZcZQtTgCbBv/1
0ocCEzVDprDMCs7E9s0jfC8=
=9kFQ
-----END PGP SIGNATURE-----

--xPLL5cPndR2UZ7Mw--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030927003752.GS16008>