The Vinum Volume Manager
Adding plexes to an existing volume
At some time after creating a volume, you may decide to add additional plexes. For example, you may want to add a plex to the volume myvol we saw above, putting its subdisk on drive b. The configuration file for this extension would look like:
plex name myvol.p1 org concat volume myvol sd size 1g drive b
To see what has happened, use the recursive listing option -r for the list command:
vinum -> l-r myvol V myvol State: up Plexes: 2 Size: 1024 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P myvol.p1 C State: initializing Subdisks: 1 Size: 1024 MB S myvol.p0.s0 State: up D: a Size: 512 MB S myvol.p1.s0 State: empty D: b Size: 1024 MB
The command l is a synonym for list, and the -r option means recursive: it displays all subordinate objects. In this example, plex myvol.p1 is 1 GB in size, although myvol.p0 is only 512 MB in size. This discrepancy is allowed, though it isn't very useful by itself: only the first half of the volume is protected against failures. As we'll see in the next section, though, this is a useful stepping stone to extending the size of a file system.
Note that you can't use the setupstate keyword here. Vinum can't know whether the existing volume contains valid data or not, so you must use the start command to synchronize the plexes.
Adding subdisks to existing plexes
After adding a second plex to myvol, it had one plex with 512 MB and another with 1024 MB. It makes sense to have the same size plexes, so the first thing we should do is add a second subdisk to the plex myvol.p0.
If you add subdisks to striped, RAID-4 or RAID-5 plexes, you will change the mapping of the data to the disks, which effectively destroys the contents. As a result, you must use the -f option. When you add subdisks to concatenated plexes, the data in the existing subdisks remains unchanged. In our case, the plex is concatenated, so we create and add the subdisk like this:
sd name myvol.p0.s1 plex myvol.p0 size 512m drive c
After adding this subdisk, the volume looks like this:
It doesn't look too happy, however:
vinum -> l -r myvol V myvol State: up Plexes: 2 Size: 1024 MB P myvol.p0 C State: corrupt Subdisks: 2 Size: 1024 MB P myvol.p1 C State: initializing Subdisks: 1 Size: 1024 MB S myvol.p0.s0 State: up D: a Size: 512 MB S myvol.p0.s1 State: empty D: c Size: 512 MB S myvol.p1.s0 State: stale D: b Size: 1024 MB
In fact, it's in as good a shape as it ever has been. The first half of myvol still contains the file system that we put on it, and it's as accessible as ever. The trouble here is that there is nothing in the other two subdisks, which are shown shaded in the figure. Vinum can't know that that is acceptable, but we do. In this case, we use some maintenance commands to set the correct object states:
vinum -> setstate up myvol.p0.s1 myvol.p0 vinum -> l -r myvol V myvol State: up Plexes: 2 Size: 1024 MB P myvol.p0 C State: up Subdisks: 2 Size: 1024 MB P myvol.p1 C State: faulty Subdisks: 1 Size: 1024 MB S myvol.p0.s0 State: up D: Size: 512 MB S myvol.p0.s1 State: up D: Size: 512 MB S myvol.p1.s0 State: stale D: Size: 1024 MB vinum -> saveconfig
The command setstate changes the state of individual objects without updating those of related objects. For example, you can use it to change the state of a plex to up even if all the subdisks are down. If used incorrectly, it can can cause severe data corruption. Unlike normal commands, it doesn't save the configuration changes, so you use saveconfig for that, after you're sure you have the correct states. Read the man page before using them for any other purpose.
Next you start the second plex:
vinum -> start myvol.p1 Reviving myvol.p1.s0 in the background vinum[446]: reviving myvol.p1.s0 vinum -> vinum[446]: myvol.p1.s0 is up some time later l command for previous prompt 3 drives: D a State: up /dev/da1s2h A: 3582/4094 MB (87%) D b State: up /dev/da2s2h A: 3070/4094 MB (74%) D c State: up /dev/da3s2h A: 3582/4094 MB (87%) 1 volumes: V myvol State: up Plexes: 2 Size: 1024 MB 2 plexes: P myvol.p0 C State: up Subdisks: 2 Size: 1024 MB P myvol.p1 C State: up Subdisks: 1 Size: 1024 MB 3 subdisks: S myvol.p0.s0 State: up D: a Size 512 MB S myvol.p1.s0 State: up D: b Size 1024 MB S myvol.p0.s1 State: up D: c Size 512 MB
The message telling you that myvol.p1.s0 is up comes after the prompt, so the next command doesn't have a prompt. At this point you have a fully mirrored, functional volume, 1 GB in size. If you now look at the contents, though, you see:
# df /mnt Filesystem 1048576-blocks Used Avail Capacity Mounted on /dev/vinum/myvol 503 1 461 0% /mnt
The volume is now 1 GB in size, but the file system on the volume is still only 512 MB. To expand it, use growfs:
# umount /mnt
# growfs /dev/vinum/myvol
We strongly recommend you to make a backup before growing the Filesystem
Did you backup your data (Yes/No) ? Yes
new file systemsize is: 524288 frags
Warning: 261920 sector(s) cannot be allocated.
growfs: 896.1MB (1835232 sectors) block size 16384, fragment size 2048
using 7 cylinder groups of 128.02MB, 8193 blks, 16512 inodes.
super-block backups (for fsck -b #) at:
1048736, 1310912, 1573088
# mount /dev/vinum/myvol /mnt
# df /mnt
Filesystem 1048576-blocks Used Avail Capacity Mounted on
/dev/vinum/myvol 881 1 809 0% /mnt