Date: Wed, 15 Mar 2000 12:03:45 +1030 From: Mark Newton <newton@internode.com.au> To: Greg Lehey <grog@lemis.com> Cc: Warner Losh <imp@village.org>, Wes Peters <wes@softweyr.com>, "K.J.Koster" <K.J.Koster@kpn.com>, Edward Gold <edgold@mindspring.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Vinum encapsulating existing partitions (was: Sysinstall 'A'uto partitioning) Message-ID: <20000315120345.A58098@internode.com.au> In-Reply-To: <20000314121217.D335@mojave.worldwide.lemis.com> References: <38C66E8E.67CD0475@softweyr.com> <59063B5B4D98D311BC0D0001FA7E452201313957@l04.research.kpn.com> <38C66E8E.67CD0475@softweyr.com> <200003090030.RAA04659@harmony.village.org> <20000309111221.B28232@internode.com.au> <20000314121217.D335@mojave.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 14, 2000 at 12:12:17PM -0800, Greg Lehey wrote:
> On Thursday, 9 March 2000 at 11:12:21 +1030, Mark Newton wrote:
>
> > Another thing which would be useful is the ability to "vinum-ize" an
> > existing filesystem without destroying it first. On Solaris and
> > IRIX I can do that by creating a logical volume with a single plex
> > which just happens to contain the same partition as the existing
> > filesystem, thereby wrapping the filesystem in the logical volume.
[ ... ]
> It's still on my wishlist, though I don't know if I have it on the web
> page (and since I'm on the road at the moment, I can't check). My
> main concern here is that I want to maintain the device name/drive ID
> independence (for those who may not know, you can take the disks of a
> Vinum array out, shuffle the device IDs and reboot, and it will still
> put the components together in the correct way).
IRIX does accomplish this (Solaris ODS doesn't). There are certain
features of the way it handles its disks which make that simpler, though:
IRIX utilizes a reserved partition on every disk (partition 8) as a
"volume header", which must start at sector 0 and can be arbitrarily
sized. The volume header contains a disklabel (which starts at
sector 0, so it overlays the disk's partition table) and zero or
more additional files in a simple filesystem (not a filesystem as
such; all files are contiguous, rammed together a-la a tar archive,
simple enough for a first-stage bootloader to understand). The most
common use for this filesystem is to contain the second-stage
bootloader (aka /boot/loader on BSD), but there are other purposes for
it as well. One of those purposes is to host XLV volume labels, which
are replicated across all disks which participate in XLV volumes.
Each XLV volume label contains a unique identifier for the spindle
which contains it. That means that the "subdisk ID" equivalent,
together with all the other info in the label, is held out-of-band,
leaving the partition containing the XLV volume element as a
repository for filesystem data and nothing else.
The advantage of this approach is, of course, that an XLV volume can
"wrap" a preexisting filesystem without destroying it. If I want to
grow my /usr partition on dks0d1s6 by using a "spare" partition on
dks1d2s0, I can do this:
irix# xlv_make
xlv_make> volume usr
usr
xlv_make> data
usr.data
xlv_make> plex
usr.data.0
xlv_make> ve dks0d1s6
usr.data.0.0
xlv_make> end
Object specification completed
xlv_make> exit
Save changes? [n] y
irix#
[ then modify fstab to mount /usr from /dev/xlv/usr instead of
/dev/dsk/dks0d1s6 and reboot. Once I've done that, I'll never
need to reboot to manage /usr again; I can perform operations
like growing the filesystem onto additional volume elements
without needing to unmount it (in fact, some operations will
fail to work if the filesystem is unmounted) ]
irix# xlv_make
xlv_make> ve foo dks1d2s0
foo
xlv_make> end
Object specification completed
xlv_make> exit
Save changes? [n] y
irix# xlv_mgr
xlv_mgr> attach ve foo usr.data.0
VE foo attached to plex usr.data.0
xlv_mgr> show -verbose all
[ you'll see that "foo" has been renamed to "usr.data.0.1" ]
xlv_mgr> exit
irix# xfs_growfs /usr
[ /usr is "grown" online (i.e: you don't need to unmount it) ]
> The obvious way to
> do that is to say "there must be a Vinum partition on this physical
> drive, but the subdisk doesn't have to be on it". That could be a
> problem for existing disks. Thoughts?
A variation might be, "There can be more than one Vinum partition on
a physical drive, and Vinum metadata can be kept in a different one
from Vinum data."
Cheers,
- mark
--
Mark Newton Email: newton@internode.com.au (W)
Network Engineer Email: newton@atdot.dotat.org (H)
Internode Systems Pty Ltd Desk: +61-8-82232999
"Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
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?20000315120345.A58098>