 | Level: Introductory Daniel Robbins (drobbins@gentoo.org), Chief architect of Gentoo Linux, IBM
01 Nov 2002 In the Advanced filesystem implementor's guide, Daniel Robbins shows you how to use the latest filesystem technologies in Linux 2.4. In this conclusion to the AFIG series, Daniel continues his discussion of the Enterprise Volume Management System for Linux, or EVMS. He shows you how to use evmsn to take a new hard drive, partition it, and create LVM volumes on it. Along the way, he fills you in on important EVMS concepts that you'll find essential as you continue your exploration of this powerful technology.
Welcome to the final installment of the Advanced filesystem implementor's
guide! In this article, Daniel picks up where he left off in his EVMS introduction and guides you through the process
of using evmsn, EVMS' ncurses-based administration tool. He shows you how to use evmsn
to take a new hard drive, partition it, and create LVM volumes on it.
Along the way, he fills you in on important EVMS concepts that you'll
find essential as you continue your exploration of this powerful
technology.
A new disk
The best way to start playing with EVMS is to find a spare hard drive and
install it in your system. Then, you can create and delete partitions and
volumes to your heart's content without putting any of your data at risk.
Below, I've followed this approach by booting a Gentoo Linux Game CD (see Resources later in this article), which actually happens to include EVMS 1.0.1 support. I booted
the CD using vmware (check Resources for link) and configured my virtual PC to
have a single SCSI disk, sda. When greeted with the login: prompt, I
logged in to the live Gentoo Linux CD-based system as root, hitting
Enter at the password prompt. Then I typed evmsn to start the ncurses
version of the EVMS administration interface. Of course, you can also
simply plug a new hard drive into your existing EVMS-enabled system if you
so choose. In addition, if you have X available, then you may want to
consider using evmsgui, the GTK+-based EVMS administration interface.
Although evmsn runs on the console using ncurses, and evmsgui uses a more modern GTK+-based interface, the interfaces of the two programs are very
similar. Experience with one should be easily transferable to the
other.
Now, let's get started with EVMS. Since I'm using the console, I type evmsn and the following screen appears:
Figure 1. The EVMS administration tool
On this screen, I can see /dev/evms/sda, the
only volume on my system. If you're running EVMS on your own box, you'll
almost certainly see at least two additional /dev/evms/???? entries listed. You can move between
each device node by using the up and down arrow keys.
You're probably wondering what these /dev/evms/??? device nodes are. At first glance, it
probably appears that they are simply copies of the respective device node
in /dev; for example, /dev/evms/sda simply
refers to the same disk as the more traditional /dev/sda device node. So, what's the point of
creating duplicate device nodes in the /dev/evms/ directory? The answer is that one of EVMS'
jobs is to create a unified namespace for all the volumes on your system,
and it creates this namespace under /dev/evms.
So, EVMS detected sda and recognized that it should be part of the EVMS
namespace, so it created the appropriate device node in /dev/evms. Now would be a good time to mention that
if you aren't using devfs, you may need to run the evms_devnode_fixup program to bring your /dev/evms namespace up-to-date.
Here's another subtle yet important factoid. While EVMS can see all the
storage resources on your system, it may not create /dev/evms/ device node entries for all of the
resources it finds. For example, my development system has two hard drives
in it, /dev/hde and /dev/hdg. However, there are no corresponding /dev/evms/hde and /dev/evms/hdg device nodes. When I look in /dev/evms/, the only device node I see is one that
represents the boot partition on my first hard disk -- /dev/evms/hde1. Now, why is there a /dev/evms/hde1 but no /dev/evms/hde? Well, it turns out that EVMS is quite
smart and recognizes that hde and hdg aren't set up to be volumes in
themselves; instead, EVMS can see that I've partitioned hde and hdg. It
can also see that I've used these partitions to create LVM logical
volumes. The space on my /dev/evms/hde2 partition is being used for a
higher-level storage object, so EVMS doesn't create the "/dev/evms/hde2" device node. Instead, it recognizes
the LVM volumes that I've created and creates device nodes for them under
/dev/evms/lvm:
Listing 1. Device nodes under /dev/evms/lvm
$ ls /dev/evms/lvm/*/* -l
brw-rw-rw- 1 root root 117, 2 Dec 31 1969 /dev/evms/lvm/mainvg/root
brw-rw-rw- 1 root root 117, 3 Dec 31 1969 /dev/evms/lvm/raid0vg/swap
brw-rw-rw- 1 root root 117, 4 Dec 31 1969 /dev/evms/lvm/raid0vg/tmplv
|
This demonstrates an important principle that EVMS follows: it will only
create device nodes for the final (not intermediate) storage
objects that it finds on your system. EVMS calls these final storage
objects "logical volumes," whether they happen actually to be disks,
partitions, or LVM logical volumes. As we'll see later, when we use the
evmsn and evmsgui administration tools, we need to explicitly create an
EVMS volume from a storage object before we can see a corresponding device
node for it in /dev/evms/. Until we transform
a storage object into a volume, EVMS will refrain from creating a device
node for it, assuming that we do not intend to use it directly but instead
plan to use it to create a higher-level storage object. By insisting that
we create a volume before a /dev/evms device
node is created, EVMS protects us from typing mke2fs
/dev/evms/foo and creating a filesystem on a device node that we
shouldn't be touching. Because of this behavior, we can have some
assurance that every device node under /dev/evms/ holds or is intended to hold either a
filesystem or swap space.
While this behavior is very sophisticated, helpful, and reduces clutter, it
does take some getting used to. To drive this point home, here's a
screenshot of evmsgui running on my development workstation. As you can
see, only four of my storage resources have been configured as volumes,
and they are all being used for filesystems or swap.
Figure 2. The evmsgui utility
Now, back to my example vmware EVMS configuration. If you look at the
first screenshot of this article, you'll notice that /dev/evms/sda is showing up as a volume even though
the disk is empty. This is just another example of EVMS being cautious;
while it couldn't detect any valid types of storage resources on our disk,
it marked the entire disk as a volume so that we would have to
delete the volume before we can start using the storage on the
disk. This is a very good behavior, since the disk theoretically
could contain some important data that EVMS simply can't recognize.
By taking this approach, EVMS avoids the risky behavior of advertising the
disk as being empty and thus possibly fooling an administrator into
overwriting a raw FreeBSD volume, for example. Again, EVMS is
sophisticated, but its behavior can be a bit confusing at first glance.
Of course, in my particular situation /dev/emvs/sda
is empty, and I need to
partition it. To do this, I need to destroy the /dev/evms/sda volume as follows. First, with /dev/evms/sda selected, I hit Enter:
Figure 3. Destroying the volume
As you can see, this brings up a sub-menu where I have the option of
viewing details about the volume, removing the volume from the storage
object, or destroying the volume. There's an important distinction between
"destroy volume" and "remove volume from storage object;" if I choose the
former, then my volume (as well as any sub-objects underneath it) will be
broken down into their base components. However, if I choose to simply
remove the volume, then the volume will be destroyed but sub-objects (if
any) will remain intact. The difference between "remove" and "destroy" is
analogous to peeling a layer off an onion versus throwing the entire thing
into a food processor.
However, in this particular case, there is only one layer to my onion, so
both options will do the same thing. I decide to choose "Destroy the
volume;" after confirming my selection and hitting any key to return to
the volumes listing, you now see the result of my action: "No logical
volumes found."
This particular view suddenly became very boring, so I'll change it.
Hitting "4" will pop up a sub-window allowing me to select a view. Right
now, I'm in the "Logical volumes" view; now let's move over to "Available
topmost storage objects." After making my selection, we can now see "sda"
in our listing again! But unlike before, we're not looking at a volume,
but a storage object. If you're following along and hit Enter on this
storage object, you'll see that we could create several things from "sda",
including an EVMS or compatibility volume.
However, we really don't want to do this -- if we were to create a volume
from sda, we'd be back where we started when we first loaded evmsn, with
a single volume that encompasses the entire disk. Instead, I want to
create partitions and then convert the partitions to volumes. To do
this, I hit "4" for (select view) and then select "Logical disks." Here I
see "sda," the logical disk. And yes, there is an important
distinction between "sda" the storage object and "sda" the logical disk.
Addressing "sda" as a storage object, we can turn it into a volume or use
it to build a higher-level storage object. But addressing "sda" as a disk
allows me to split the disk up into partitions (called "segments" in
EVMS-speak), which in turn can be used as storage objects. To do this, I
hit Enter, popping up a menu that gives me the option of assigning a
segment manager to the disk:
Figure 4. Assigning a segment manager
Now, if segments are the same things as partitions, you may be wondering
what a segment manager is. Think of a segment manager as a "partitioning
method" or scheme. Once we choose a segment manager, EVMS will put some
metadata on our disk, creating a master boot record and marking the rest
of the space on our disk as "freespace," available for new segments. To
make this happen, I choose "DefaultSegMgr" from the menu on my screen, hit
Enter again, and press space. Select "sda" as the object to receive a
segment manager. Then, I hit Enter again, choose a disk type of "Linux"
("OS/2" is also available as an option), and hit Enter to continue. After
pressing a key, I now hit "4" (select view) and select "Disk Segments" to
see the new segments that I've created:
Figure 5. Creating new segments
My disk now has a master boot record and I'm ready to create new
partitions, called "segments" in EVMS-speak. As I create new segments, my
"sda_freespace1" segment will shrink; if I create partitions out of all
of the free space on my disk, the sda_freespace1 segment will completely
disappear. It's also possible that a tiny remainder sda_freespace1 will
continue to exist if the available storage on the hard drive does map
cleanly to the partition sizes that I choose.
Now, to create those segments, I hit Enter when hovering over
"sda_freespace1" and then select "Create a New Segment." Next, I select
the DefaultSegMgr plugin, and accept the use of the sda_freespace1 object
by hitting space, then Enter. Next, I'll create a small bootable partition
at the beginning of the disk to hold my kernels. To do this, I'll hit
space twice and then type "100" to set the partition size to 100 MB, then
set "Bootable" to true by hitting space twice over the Bootable option.
Finally, I'll hit Enter to create the new partition. By repeating these
steps, I then create other partitions for my filesystems and swap. Some
notes: if you need to create more than four partitions, remember to toggle
the "Primary Partition" option after creating your boot volume. Also
remember to set the "Partition Type" to "Linux Swap" when creating your
swap partition.
The final step is to hit Enter over "sda1," "sda2," and "sda3." A menu
appears showing an option that reads "Create Compatibility Volume from the
Segment." When I select this option, my segment will be configured to
house a full-fledged logical volume, meaning that it will now have a
device node under /dev/evms/. In addition,
because I chose to create a compatibility volume, the new volume
will be usable even if I happen to reboot my system with a non-EVMS
kernel. If I had chosen "Create EVMS Volume," then this wouldn't have been
the case. Note that EVMS versions 1.1.0 and later allow you to convert
compatibility volumes into EVMS volumes, and vice-versa.
Conclusion
So there you have it, I've partitioned a single system disk using EVMS.
While not an earth-shattering accomplishment, such an experience will help
to give you the EVMS foundation you need before attempting things like
creating storage containers, LVM logical volumes, RAID volumes, snapshots,
and other goodies. Of course, I didn't have room to cover these topics in
this article, but I hope to be able to touch on some of these EVMS
applications intermittently throughout the next year. But first, on to
other things; it's time to bring the Advanced filesystem implementor's
guide to a close. I hope you've enjoyed the ride :)
Resources - Daniel introduced EVMS in Part 12 of the Advanced filesystem implementor's guide, "Introduction to EVMS" (developerWorks, Octorber 2002).
- Visit the official development home of the EVMS project on SourceForge, where you can subscribe to mailing lists and read EVMS documentation, among other things.
- Visit the #evms channel on the freenode (formerly Open Projects Net) IRC network. Several EVMS developers regularly hang out in #evms.
- VMware is a virtual machine software package.
- Learn more about Gentoo Linux.
- An easy way to begin exploring EVMS is to download a Gentoo Linux Game/Install
mini-CD -- grab
livecd-ut2003-i586-1.4.1.iso from the
Gentoo 1.4 x86 download directory.
- Find related information on Linux Software RAID in Daniel's series:
- Daniel explores Linux Logical Volume Management in:
- Find more Linux articles in the developerWorks Linux zone.
About the author | | | Residing in Albuquerque, New Mexico, Daniel Robbins is the Chief Architect
of Gentoo Linux, an advanced
ports-based Linux for x86, PowerPC, Sparc, and Sparc64 systems. He has
also served as a contributing author for several books, including
Samba Unleashed and SuSE Linux
Unleashed. Daniel enjoys spending time with his wife, Mary,
and his daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org.
|
Rate this page
| |
