Date: Sun, 27 Jun 1999 13:57:36 +0930 From: Greg Lehey <grog@lemis.com> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Aaron Smith <aaron-fbsd@mutex.org>, freebsd-hackers@FreeBSD.ORG Subject: Simplifying Vinum (was: ufs/ffs resize?) Message-ID: <19990627135736.F427@freebie.lemis.com> In-Reply-To: <69539.930380030@zippy.cdrom.com>; from Jordan K. Hubbard on Fri, Jun 25, 1999 at 11:53:50PM -0700 References: <19990626113635.Y427@freebie.lemis.com> <69539.930380030@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 25 June 1999 at 23:53:50 -0700, Jordan K. Hubbard wrote:
>> I agree with the approach. But why write a simplistic volume manager
>> when we already have vinum?
>
> vinum is far from simplistic, but I suppose it might also do. :)
>
> Still, it would someday be nice if you could use vinum as the very
> powerful swiss-army knife that it currently is OR as a dull axe to
> simply concatenate, ala ccd, n partitions together in some extremely
> straight-forward fashion. That is to say, instead of having to think
> about subdisks on plexes on foxes on clockses (sorry Dr. Seuss) when all
> you wanted to do is whack some space together in a simple and obvious way,
> you could say something like "vinum -C /dev/wd0s1a /dev/sd1s2 /dev/sd2"
> in order to concatenate wd0/slice 1/partition a, sd1/all of slice 2,
> and all of drive sd2 together. vinum would choose the volume name itself
> and return it, from this it being possible to contrive the device pathname
> for newfs and mount.
Well, that's an interesting viewpoint. It's not Vinum, of course,
that we need to change, just the control program.
> One might then logically assume the next step would be trivial insertion
> and deletion options, like:
>
> vinum -i /dev/something volumename
>
> to insert a new partition into existing volume volumename and
>
> vinum -d /dev/something volumename
>
> to delete /dev/something from volumename, assuming that it's found
> in that volume. I guess while I'm dreaming, you could use -M to
> also create trivial mirror sets and -i and -d could act on those
> as well. :)
I think you'll find, once you get that far, that things are anything
but trivial. I'm certainly open to suggestions, but consider:
vinum -i /dev/something volumename
Where does it insert it? What if the volume has more than one plex,
which it will in the case of a mirror?
I'm not saying that this can't be done, but one of the reasons for the
relatively formal way that Vinum does things is precisely to make it
more difficult to make misassumptions.
> Lest anyone get the wrong idea, let me also hastily note here that I'm
> not trying to suggest that vinum should shed functionality or become
> dumbed-down - the current amount of flexibility is good and probably
> in full accord with "the unix way" insofar as I understand vinum's
> operation. :)
Yes, I think I understand that relatively well.
> It's also more than a little indimidating to new users, however,
> many of whom only want to use it for the most simplistic scenarios
> anyway. Some big dials to go with all the small dials can't hurt,
> can it? :)
Not if they're done well. I'm open to suggestions. Here are couple
of possibilities: add commands "cat", "stripe" and "mirror":
vinum cat /dev/da1h /dev/da2h
vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h
vinum mirror /dev/da1h /dev/da2h
vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h
The first one would take the drives and create a concatenated volume
out of them. The second would do the same thing but make a striped
volume. The third would make a simple concatenated mirror, and the
fourth... yes, what about the fourth? Four plexes, each of one
volume? Two plexes, each concatenating two drives? You tell me.
And what about the names? It seems tacky to have to write down the
name that Vinum chooses. How about adding a name parameter, either
implicitly or explicitly? For example,
vinum cat myvol /dev/da1h /dev/da2h
vinum cat -n myvol /dev/da1h /dev/da2h
Greg
--
See complete headers for address, home page and phone numbers
finger grog@lemis.com for PGP public key
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990627135736.F427>