Logical volume management is traditionally associated with large installations containing many disks but it is equally suited to small systems with a single disk or maybe two.

One of the difficult decisions facing a new user installing Linux for the first time is how to partition the disk drive. The need to estimate just how much space is likely to be needed for system files and user files makes the installation more complex than is necessary and some users simply opt to put all their data into one large partition in an attempt to avoid the issue.

Once the user has guessed how much space is needed for /home /usr / (or has let the installation program do it) then is quite common for one of these partitions to fill up even if there is plenty of disk space in one of the other partitions.

With logical volume management, the whole disk would be allocated to a single volume group and logical volumes created to hold the / /usr and /home file systems. If, for example the /home logical volume later filled up but there was still space available on /usr then it would be possible to shrink /usr by a few megabytes and reallocate that space to /home.

Another alternative would be to allocate minimal amounts of space for each logical volume and leave some of the disk unallocated. Then, when the partitions start to fill up, they can be expanded as necessary.

As an example: Joe buys a PC with an 8.4 Gigabyte disk on it and installs Linux using the following partitioning system:

/boot    /dev/hda1     10 Megabytes
swap     /dev/hda2    256 Megabytes
/        /dev/hda3      2 Gigabytes
/home    /dev/hda4      6 Gigabytes
        

This, he thinks, will maximize the amount of space available for all his MP3 files.

Sometime later Joe decides that he want to install the latest office suite and desktop UI available but realizes that the root partition isn't large enough. But, having archived all his MP3s onto a new writable DVD drive there is plenty of space on /home.

His options are not good:

With LVM this becomes much easier:

Jane buys a similar PC but uses LVM to divide up the disk in a similar manner:

/boot     /dev/hda1        10 Megabytes
swap      /dev/vg00/swap   256 Megabytes
/         /dev/vg00/root     2 Gigabytes
/home     /dev/vg00/home     6 Gigabytes

         

When she hits a similar problem she can reduce the size of /home by a gigabyte and add that space to the root partition.

Suppose that Joe and Jane then manage to fill up the /home partition as well and decide to add a new 20 Gigabyte disk to their systems.

Joe formats the whole disk as one partition (/dev/hdb1) and moves his existing /home data onto it and uses the new disk as /home. But he has 6 gigabytes unused or has to use symlinks to make that disk appear as an extension of /home, say /home/joe/old-mp3s.

Jane simply adds the new disk to her existing volume group and extends her /home logical volume to include the new disk. Or, in fact, she could move the data from /home on the old disk to the new disk and then extend the existing root volume to cover all of the old disk.

The benefits of logical volume management are more obvious on large systems with many disk drives.

Managing a large disk farm is a time-consuming job, made particularly complex if the system contains many disks of different sizes. Balancing the (often conflicting) storage requirements of various users can be a nightmare.

User groups can be allocated to volume groups and logical volumes and these can be grown as required. It is possible for the system administrator to "hold back" disk storage until it is required. It can then be added to the volume(user) group that has the most pressing need.

When new drives are added to the system, it is no longer necessary to move users files around to make the best use of the new storage; simply add the new disk into an existing volume group or groups and extend the logical volumes as necessary.

It is also easy to take old drives out of service by moving the data from them onto newer drives - this can be done online, without disrupting user service.

The Volume Group is the highest level abstraction used within the LVM. It gathers together a collection of Logical Volumes and Physical Volumes into one administrative unit.

A physical volume is typically a hard disk, though it may well just be a device that 'looks' like a hard disk (eg. a software raid device).

The equivalent of a disk partition in a non-LVM system. The LV is visible as a standard block device; as such the LV can contain a file system (eg. /home).

Each physical volume is divided chunks of data, known as physical extents, these extents have the same size as the logical extents for the volume group.

Each logical volume is split into chunks of data, known as logical extents. The extent size is the same for all logical volumes in the volume group.

A concrete example will help:

Lets suppose we have a volume group called VG1, this volume group has a physical extent size of 4MB. Into this volume group we introduce 2 hard disk partitions, /dev/hda1 and /dev/hdb1. These partitions will become physical volumes PV1 and PV2 (more meaningful names can be given at the administrators discretion). The PV's are divided up into 4MB chunks, since this is the extent size for the volume group. The disks are different sizes and we get 99 extents in PV1 and 248 extents in PV2. We now can create ourselves a logical volume, this can be any size between 1 and 347 (248 + 99) extents. When the logical volume is created a mapping is defined between logical extents and physical extents, eg. logical extent 1 could map onto physical extent 51 of PV1, data written to the first 4 MB of the logical volume in fact be written to the 51st extent of PV1.

The administrator can choose between a couple of general strategies for mapping logical extents onto physical extents:

A wonderful facility provided by LVM is 'snapshots'. This allows the administrator to create a new block device which presents an exact copy of a logical volume, frozen at some point in time. Typically this would be used when some batch processing, a backup for instance, needs to be performed on the logical volume, but you don't want to halt a live system that is changing the data. When the snapshot device has been finished with the system administrator can just remove the device. This facility does require that the snapshot be made at a time when the data on the logical volume is in a consistent state - the VFS-lock patch for LVM1 makes sure that some filesystems do this automatically when a snapshot is created, and many of the filesystems in the 2.6 kernel do this automatically when a snapshot is created without patching.

LVM1 has read-only snapshots. Read-only snapshots work by creating an exception table, which is used to keep track of which blocks have been changed. If a block is to be changed on the origin, it is first copied to the snapshot, marked as copied in the exception table, and then the new data is written to the original volume.

In LVM2, snapshots are read/write by default. Read/write snapshots work like read-only snapshots, with the additional feature that if data is written to the snapshot, that block is marked in the exception table as used, and never gets copied from the original volume. This opens up many new possibilities that were not possible with LVM1's read-only snapshots. One example is to snapshot a volume, mount the snapshot, and try an experimental program that change files on that volume. If you don't like what it did, you can unmount the snapshot, remove it, and mount the original filesystem in its place. It is also useful for creating volumes for use with Xen. You can create a disk image, then snapshot it and modify the snapshot for a particular domU instance. You can then create another snapshot of the original volume, and modify that one for a different domU instance. Since the only storage used by a snapshot is blocks that were changed on the origin or the snapshot, the majority of the volume is shared by the domU's.

Note: the state of code in the CVS repository fluctuates wildly. It will contain bugs. Maybe ones that will crash LVM or the kernel. It may not even compile. Consider it alpha-quality code. You could lose data. You have been warned.

To follow the development progress of LVM, subscribe to the LVM mailing lists, linux-lvm and the appropriate commit list (see Section 1, “Mail lists”).

To build LVM from the CVS sources, you must have several GNU tools:

To make life easier in the future with regards to updating the CVS tree create the file $HOME/.cvsrc and insert the following lines. This configures useful defaults for the three most commonly used CVS commands. Do this now before proceeding any further.

diff -u -b -B
checkout -P
update -d -P

         

Also, if you are on a slow net link (like a dialup), you will want to add a line containing cvs -z5 in this file. This turns on a useful compression level for all CVS commands.

CVS commands work from anywhere inside the source tree, and recurse downward. So if you happen to issue an update from inside the `tools' subdirectory it will work fine, but only update the tools directory and it's subdirectories. In the following command examples it is assumed that you are at the top of the source tree.

Code changes are made fairly frequently in the CVS repository. Announcements of this are automatically sent to the lvm-commit list.

You can update your copy of the sources to match the master repository with the update command. It is not necessary to check out a new copy. Using update is significantly faster and simpler, as it will download only patches instead of entire files and update only those files that have changed since your last update. It will automatically merge any changes in the CVS repository with any local changes you have made as well. Just cd to the directory you'd like to update and then type the following.

 # cvs update 
         

If you did not specify a tag when you checked out the source, this will update your sources to the latest version on the main branch. If you specified a branch tag, it will update to the latest version on that branch. If you specified a version tag, it will not do anything.

Discuss your ideas on the developers list before you start. Someone may be working on the same thing you have in mind or they may have some good ideas about how to go about it.

So, have you found a bug you want to fix? Want to implement a feature from the TODO list? Got a new feature to implement? Hacking the code couldn't be easier. Just edit your copy of the sources. No need to copy files to .orig or anything. CVS has copies of the originals.

When you have your code in a working state and have tested as best you can with the hardware you have, generate a patch against the current sources in the CVS repository.

 # cvs update
 # cvs diff > patchfile
         

Mail the patch to the linux-lvm or dm-devel list (Section 1, “Mail lists”) with a description of what changes or additions you implemented.

If someone else has been working on the same files as you have, you may find that there are conflicting modifications. You'll discover this when you try to update your sources.

 # cvs update 

 RCS file: LVM/tools/pvcreate.c,v
 retrieving revision 1.5
 retrieving revision 1.6
 Merging differences between 1.5 and 1.6 into pvcreate.c
 rcsmerge: warning: conflicts during merge
 cvs server: conflicts found in tools/pvcreate.c
 C tools/pvcreate.c

         

Don't panic! Your working file, as it existed before the update, is saved under the filename .#pvcreate.c.1.5. You can always recover it should things go horribly wrong. The file named `pvcreate.c' now contains both the old (i.e. your) version and new version of lines that conflicted. You simply edit the file and resolve each conflict by deleting the unwanted version of the lines involved.

 <<<<<<< pvcreate.c
    j++;
 =======
    j--;
 >>>>>>> 1.6

         

Don't forget to delete the lines with all the ``<'', ``='', and ``>'' symbols.

Device mapper is in 2.6.9 and later, so you just need to make sure it is enabled either as a module or builtin to the kernel. Look for /sys/class/misc/device-mapper or look in /proc/devices for a device-mapper entry to see if it is enabled. If neither are there, try modprobe dm_mod, then check again. For versions previous to 2.6.9, either you or your distro must patch the kernel to support it. Check the device mapper web page for more information.

To use LVM 1 you will have to build the LVM 1 kernel module (recommended), or if you prefer rebuild the kernel with the LVM 1 code statically linked into it.

Your Linux system is probably based on one of the popular distributions (eg., Red Hat, SuSE, Debian) in which case it is possible that you already have the LVM 1 module. Check the version of the tools you have on your system. You can do this by running any of the LVM command line tools with the '-h' flag. Use pvscan -h if you don't know any of the commands. If the version number listed at the top of the help listing is LVM 1.0.8, use your current setup and avoid the rest of this section.

 # modprobe lvm-mod 
         

It is necessary to edit the file /etc/rc.d/rc.boot. Look for the line that says “Mounting local filesystems” and insert the vgscan and vgchange commands just before it.

You may also want to edit the file /etc/rc.d/init.d/halt to deactivate the volume groups at shutdown. Insert the

 vgchange -an 
            

command near the end of this file just after the filesystems are unmounted or mounted read-only, before the comment that says “Now halt or reboot”.

If you download the Debian lvm tool package, an initscript should be installed for you.

If you are installing LVM from source, you will still need to build your own initscript:

Create a startup script in /etc/init.d/lvm containing the following:

#!/bin/sh

case "$1" in
  start)
	/sbin/vgscan
	/sbin/vgchange -ay
        ;;
  stop)
	/sbin/vgchange -an
        ;;
  restart|force-reload)
	;;
esac

exit 0
            

Then execute the commands

 # chmod 0755 /etc/init.d/lvm
 # update-rc.d lvm start 26 S . stop 82 1 .

            

Note the dots in the last command.

No initscript modifications should be necessary for current versions of Mandrake.

For Redhat 7.0 and up, you should not need to modify any initscripts to enable LVM at boot time if LVM is built into the kernel. If LVM is built as a module, it may be necessary to modify /etc/rc.d/rc.sysinit to load the LVM module by adding “modprobe lvm-mod” before the section that reads:

# LVM initialization, take 2 (it could be on top of RAID)
if [ -e /proc/lvm -a -x /sbin/vgchange -a -f /etc/lvmtab ]; then
        action $"Setting up Logical Volume Management:" /sbin/vgscan &&
        /sbin/vgchange -a y
        fi

For versions of Redhat older than 7.0, it is necessary to edit the file /etc/rc.d/rc.sysinit. Look for the line that says “Mount all other filesystems” and insert the vgscan and vgchange commands just before it. You should be sure that your root file system is mounted read/write before you run the LVM commands.

You may also want to edit the file /etc/rc.d/init.d/halt to deactivate the volume groups at shutdown. Insert the

vgchange -an
            

command near the end of this file just after the filesystems are mounted read-only, before the comment that says “Now halt or reboot”.

Slackware 8.1 requires no updating of boot time scripts in order to make LVM work.

For versions previous to Slackware 8.1, you should apply the following patch to /etc/rc.d/rc.S

cd /etc/rc.d
cp -a rc.S rc.S.old
patch -p0 < rc.S.diff
            

(the cp part to make a backup in case).

----- snip snip file: rc.S.diff---------------
--- rc.S.or	Tue Jul 17 18:11:20 2001
+++ rc.S	Tue Jul 17 17:57:36 2001
@@ -4,6 +4,7 @@
 #
 # Mostly written by:  Patrick J. Volkerding, <volkerdi@slackware.com>
 #
+# Added LVM support <tgs@iafrica.com>

 PATH=/sbin:/usr/sbin:/bin:/usr/bin

@@ -28,19 +29,21 @@
   READWRITE=yes
 fi

+
 # Check the integrity of all filesystems
 if [ ! READWRITE = yes ]; then
-  /sbin/fsck -A -a
+  /sbin/fsck -a /
+  # Check only the root fs first, but no others
   # If there was a failure, drop into single-user mode.
   if [ ? -gt 1 ] ; then
     echo
     echo
-    echo "*******************************************************"
-    echo "*** An error occurred during the file system check. ***"
-    echo "*** You will now be given a chance to log into the  ***"
-    echo "*** system in single-user mode to fix the problem.  ***"
-    echo "*** Running 'e2fsck -v -y <partition>' might help.  ***"
-    echo "*******************************************************"
+    echo "************************************************************"
+    echo "*** An error occurred during the root file system check. ***"
+    echo "*** You will now be given a chance to log into the       ***"
+    echo "*** system in single-user mode to fix the problem.       ***"
+    echo "*** Running 'e2fsck -v -y <partition>' might help.       ***"
+    echo "************************************************************"
     echo
     echo "Once you exit the single-user shell, the system will reboot."
     echo
@@ -82,6 +85,44 @@
     echo -n "get into your machine and start looking for the problem. "
     read junk;
   fi
+  # okay / fs is clean, and mounted as rw
+  # This was an addition, limits vgscan to /proc thus
+  # speeding up the scan immensely.
+  /sbin/mount /proc
+
+  # Initialize Logical Volume Manager
+  /sbin/vgscan
+  /sbin/vgchange -ay
+
+  /sbin/fsck -A -a -R
+  #Check all the other filesystem, including the LVM's, excluding /
+
+  # If there was a failure, drop into single-user mode.
+  if [ ? -gt 1 ] ; then
+    echo
+    echo
+    echo "*******************************************************"
+    echo "*** An error occurred during the file system check. ***"
+    echo "*** You will now be given a chance to log into the  ***"
+    echo "*** system in single-user mode to fix the problem.  ***"
+    echo "*** Running 'e2fsck -v -y <partition>' might help.  ***"
+    echo "*** The root filesystem is ok and mounted readwrite ***"
+    echo "*******************************************************"
+    echo
+    echo "Once you exit the single-user shell, the system will reboot."
+    echo
+
+    PS1="(Repair filesystem) #"; export PS1
+    sulogin
+
+    echo "Unmounting file systems."
+    umount -a -r
+    mount -n -o remount,ro /
+    echo "Rebooting system."
+    sleep 2
+    reboot
+  fi
+
 else
   echo "Testing filesystem status: read-write filesystem"
   if cat /etc/fstab | grep ' / ' | grep umsdos 1> /dev/null 2> /dev/null ;
then
@@ -111,14 +152,16 @@
     echo -n "Press ENTER to continue. "
     read junk;
   fi
+
 fi

+
 # remove /etc/mtab* so that mount will create it with a root entry
 /bin/rm -f /etc/mtab* /etc/nologin /etc/shutdownpid

 # mount file systems in fstab (and create an entry for /)
 # but not NFS or SMB because TCP/IP is not yet configured
-/sbin/mount -a -v -t nonfs,nosmbfs
+/sbin/mount -a -v -t nonfs,nosmbfs,proc

 # Clean up temporary files on the /var volume:
 /bin/rm -f /var/run/utmp /var/run/*.pid /var/log/setup/tmp/*
--snip snip snip end of file---------------

         

No changes should be necessary from 6.4 onward as LVM is included

Change into the LVM directory and do a ./configure followed by make. This will make all of the libraries and programs.

If the need arises you can change some options with the configure script. Do a ./configure --help to determine which options are supported. Most of the time this will not be necessary.

There should be no errors from the build process. If there are, see Reporting Errors and Bugs on how to report this.

You are welcome to fix them and send us the patches too. Patches are generally sent to the linux-lvm list.

After the LVM source compiles properly, simply run make install to install the LVM library and tools onto your system.

To remove the library and tools you just installed, run make remove. You must have the original source tree you used to install LVM to use this feature.

There are just a few simple steps to transition this setup, but it is still recommended that you backup your data before you try it. You have been warned.

This is relatively straightforward if you follow the steps carefully. It is recommended you have a good backup and a suitable rescue disk handy just in case.

The “normal” way of running an LVM root file system is to have a single non-LVM partition called /boot which contains the kernel and initial RAM disk needed to start the system. The system I upgraded was as follows:

 # df

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/rootvg/root        253871     93384    147380  39% /
/dev/hda1                17534     12944      3685  78% /boot
/dev/rootvg/home       4128448      4568   3914168   0% /home
/dev/rootvg/usr        1032088    332716    646944  34% /usr
/dev/rootvg/var         253871     31760    209004  13% /var

            

/boot contains the old kernel and an initial RAM disk as well as the LILO boot files and the following entry in /etc/lilo.conf

 # ls /boot

System.map                 lost+found              vmlinux-2.2.16lvm
map                        module-info	           boot.0300  
boot.b                     os2_d.b                 chain.b
initrd.gz                  

 # tail /etc/lilo.conf

image=/boot/vmlinux-2.2.16lvm
        label=lvm08
        read-only
        root=/dev/rootvg/root
        initrd=/boot/initrd.gz
        append="ramdisk_size=8192"

            

When you are happy with the new system remember to change the ``default='' entry in your lilo.conf file so that it is the default kernel.

Before you can use a disk or disk partition as a physical volume you will have to initialize it:

For entire disks:

For partitions:

Use the 'vgcreate' program:

# vgcreate my_volume_group /dev/hda1 /dev/hdb1 
        

NOTE: If you are using LVM 1 with devfs it is essential to use the full devfs name of the device rather than the symlinked name in /dev. So the above would be:

# vgcreate my_volume_group /dev/ide/host0/bus0/target0/lun0/part1 \
                           /dev/ide/host0/bus0/target1/lun0/part1
        

LVM 2 does not have this restriction.

You can also specify the extent size with this command if the default of 32MB is not suitable for you with the '-s' switch. In addition you can put some limits on the number of physical or logical volumes the volume can have.

After rebooting the system or running vgchange -an, you will not be able to access your VGs and LVs. To reactivate the volume group, run:

# vgchange -a y my_volume_group
        

Make sure that no logical volumes are present in the volume group, see later section for how to do this.

Deactivate the volume group:

# vgchange -a n my_volume_group
        

Now you actually remove the volume group:

# vgremove my_volume_group
        

Use 'vgextend' to add an initialized physical volume to an existing volume group.

# vgextend my_volume_group /dev/hdc1
                                    ^^^^^^^^^ new physical volume
        

Make sure that the physical volume isn't used by any logical volumes by using then 'pvdisplay' command:

# pvdisplay /dev/hda1

--- Physical volume ---
PV Name               /dev/hda1
VG Name               myvg
PV Size               1.95 GB / NOT usable 4 MB [LVM: 122 KB]
PV#                   1
PV Status             available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       4096
Total PE              499
Free PE               0
Allocated PE          499
PV UUID               Sd44tK-9IRw-SrMC-MOkn-76iP-iftz-OVSen7

        

If the physical volume is still used you will have to migrate the data to another physical volume using pvmove.

Then use 'vgreduce' to remove the physical volume:

# vgreduce my_volume_group /dev/hda1
        

To create a 1500MB linear LV named 'testlv' and its block device special '/dev/testvg/testlv':

# lvcreate -L1500 -ntestlv testvg
        

To create a 100 LE large logical volume with 2 stripes and stripe size 4 KB.

# lvcreate -i2 -I4 -l100 -nanothertestlv testvg
        

If you want to create an LV that uses the entire VG, use vgdisplay to find the “Total PE” size, then use that when running lvcreate.

# vgdisplay testvg | grep "Total PE"
Total PE              10230
# lvcreate -l 10230 testvg -n mylv
        

This will create an LV called mylv filling the testvg VG.

If you want the logical volume to be allocated from a specific physical volume in the volume group, specify the PV or PVs at the end of the lvcreate command line.

# lvcreate -L 1500 -ntestlv testvg /dev/sdg
        

A logical volume must be closed before it can be removed:

# umount /dev/myvg/homevol
# lvremove /dev/myvg/homevol
lvremove -- do you really want to remove "/dev/myvg/homevol"? [y/n]: y
lvremove -- doing automatic backup of volume group "myvg"
lvremove -- logical volume "/dev/myvg/homevol" successfully removed
        

To extend a logical volume you simply tell the lvextend command how much you want to increase the size. You can specify how much to grow the volume, or how large you want it to grow to:

# lvextend -L12G /dev/myvg/homevol
lvextend -- extending logical volume "/dev/myvg/homevol" to 12 GB
lvextend -- doing automatic backup of volume group "myvg"
lvextend -- logical volume "/dev/myvg/homevol" successfully extended
        

will extend /dev/myvg/homevol to 12 Gigabytes.

# lvextend -L+1G /dev/myvg/homevol
lvextend -- extending logical volume "/dev/myvg/homevol" to 13 GB
lvextend -- doing automatic backup of volume group "myvg"
lvextend -- logical volume "/dev/myvg/homevol" successfully extended
        

will add another gigabyte to /dev/myvg/homevol.

After you have extended the logical volume it is necessary to increase the file system size to match. how you do this depends on the file system you are using.

By default, most file system resizing tools will increase the size of the file system to be the size of the underlying logical volume so you don't need to worry about specifying the same size for each of the two commands.

Logical volumes can be reduced in size as well as increased. However, it is very important to remember to reduce the size of the file system or whatever is residing in the volume before shrinking the volume itself, otherwise you risk losing data.

To take a disk out of service it must first have all of its active physical extents moved to one or more of the remaining disks in the volume group. There must be enough free physical extents in the remaining PVs to hold the extents to be copied from the old disk. For further detail see Section 5, “Removing an Old Disk”.

LVM allows you to create PVs (physical volumes) out of almost any block device so, for example, the following are all valid commands and will work quite happily in an LVM environment:

# pvcreate /dev/sda1
# pvcreate /dev/sdf
# pvcreate /dev/hda8
# pvcreate /dev/hda6
# pvcreate /dev/md1
        

In a “normal” production system it is recommended that only one PV exists on a single real disk, for the following reasons:

However it may be desirable to do this for some reasons:

If you do have a disk with more than one partition and both of those partitions are in the same volume group, take care to specify which partitions are to be included in a logical volume when creating striped volumes.

The recommended method of partitioning a disk is to create a single partition that covers the whole disk. This avoids any nasty accidents with whole disk drive device nodes and prevents the kernel warning about unknown partition types at boot-up.

You need to be especially careful on SPARC systems where the disks have Sun disk labels on them.

The normal layout for a Sun disk label is for the first partition to start at block zero of the disk, thus the first partition also covers the area containing the disk label itself. This works fine for ext2 filesystems (and is essential for booting using SILO) but such partitions should not be used for LVM. This is because LVM starts writing at the very start of the device and will overwrite the disk label.

If you want to use a disk with a Sun disk label with LVM, make sure that the partition you are going to use starts at cylinder 1 or higher.

For this recipe, the setup has three SCSI disks that will be put into a logical volume using LVM. The disks are at /dev/sda, /dev/sdb, and /dev/sdc.

# pvcreate /dev/sda
# pvcreate /dev/sdb
# pvcreate /dev/sdc
          

# lvcreate -L1G -nmy_logical_volume my_volume_group
lvcreate -- doing automatic backup of "my_volume_group"
lvcreate -- logical volume "/dev/my_volume_group/my_logical_volume" successfully created
          

# mke2fs /dev/my_volume_group/my_logical_volume
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
9 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Writing inode tables: done
Writing superblocks and filesystem accounting information: done
               

# mount /dev/my_volume_group/my_logical_volume /mnt
# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1              1311552    628824    616104  51% /
/dev/my_volume_group/my_logical_volume
                       1040132        20    987276   0% /mnt
          

For this recipe, the setup has three SCSI disks that will be put into a logical volume using LVM. The disks are at /dev/sda, /dev/sdb, and /dev/sdc.

# pvcreate /dev/sda
# pvcreate /dev/sdb
# pvcreate /dev/sdc
          

# lvcreate -i3 -I4 -L1G -nmy_logical_volume my_volume_group
lvcreate -- rounding 1048576 KB to stripe boundary size 1056768 KB / 258 PE
lvcreate -- doing automatic backup of "my_volume_group"
lvcreate -- logical volume "/dev/my_volume_group/my_logical_volume" successfully created
          

# mke2fs /dev/my_volume_group/my_logical_volume
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
132192 inodes, 264192 blocks
13209 blocks (5.00%) reserved for the super user
First data block=0
9 block groups
32768 blocks per group, 32768 fragments per group
14688 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Writing inode tables: done
Writing superblocks and filesystem accounting information: done
          

# mount /dev/my_volume_group/my_logical_volume /mnt
               

# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1              1311552    628824    616104  51% /
/dev/my_volume_group/my_logical_volume
                       1040132        20    987276   0% /mnt
          

Following on from the previous example we now want to use the extra space in the "ops" volume group to make a database backup every evening. To ensure that the data that goes onto the tape is consistent we use an LVM snapshot logical volume.

A snapshot volume is a special type of volume that presents all the data that was in the volume at the time the snapshot was created. For a more detailed description, see Section 8, “Snapshots”, Snapshots. This means we can back up that volume without having to worry about data being changed while the backup is going on, and we don't have to take the database volume offline while the backup is taking place.

# lvcreate -L592M -s -n dbbackup /dev/ops/databases 
lvcreate -- WARNING: the snapshot must be disabled if it gets full
lvcreate -- INFO: using default snapshot chunk size of 64 KB for "/dev/ops/dbbackup"
lvcreate -- doing automatic backup of "ops"
lvcreate -- logical volume "/dev/ops/dbbackup" successfully created

          

# mkdir /mnt/ops/dbbackup
# mount /dev/ops/dbbackup /mnt/ops/dbbackup
mount: block device /dev/ops/dbbackup is write-protected, mounting read-only
          

# mount /dev/ops/dbbackup /mnt/ops/dbbackup -onouuid,ro
          

# tar -cf /dev/rmt0 /mnt/ops/dbbackup
tar: Removing leading `/' from member names
          

# umount /mnt/ops/dbbackup
# lvremove /dev/ops/dbbackup 
lvremove -- do you really want to remove "/dev/ops/dbbackup"? [y/n]: y
lvremove -- doing automatic backup of volume group "ops"
              lvremove -- logical volume "/dev/ops/dbbackup" successfully removed
          

Say you have an old IDE drive on /dev/hdb. You want to remove that old disk but a lot of files are on it.

# pvmove /dev/hdb
pvmove -- moving physical extents in active volume group "dev"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- 249 extents of physical volume "/dev/hdb" successfully moved
          

# vgreduce dev /dev/hdb
vgreduce -- doing automatic backup of volume group "dev"
vgreduce -- volume group "dev" successfully reduced by physical volume:
vgreduce -- /dev/hdb
            

# pvcreate /dev/sdf
pvcreate -- physical volume "/dev/sdf" successfully created
            

# vgextend dev /dev/sdf
vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
vgextend -- doing automatic backup of volume group "dev"
vgextend -- volume group "dev" successfully extended
            

# pvmove /dev/hdb /dev/sdf
pvmove -- moving physical extents in active volume group "dev"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- 249 extents of physical volume "/dev/hdb" successfully moved
            

# vgreduce dev /dev/hdb
vgreduce -- doing automatic backup of volume group "dev"
vgreduce -- volume group "dev" successfully reduced by physical volume:
vgreduce -- /dev/hdb
            

It is quite easy to move a whole volume group to another system if, for example, a user department acquires a new server. To do this we use the vgexport and vgimport commands.

# unmount /mnt/design/users
          

# vgchange -an design
vgchange -- volume group "design" successfully deactivated
          

# vgexport design
vgexport -- volume group "design" successfully exported
          

# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- inactive PV "/dev/sdb1"  is in EXPORTED VG "design" [996 MB / 996 MB free]
pvscan -- inactive PV "/dev/sdb2"  is in EXPORTED VG "design" [996 MB / 244 MB free]
pvscan -- total: 2 [1.95 GB] / in use: 2 [1.95 GB] / in no VG: 0 [0]
          

# vgimport design
  Volume group "vg" successfully imported
          

# vgimport design /dev/sdb1 /dev/sdb2
vgimport -- doing automatic backup of volume group "design"
vgimport -- volume group "design" successfully imported and activated
          

# vgchange -ay design
          

# mkdir -p /mnt/design/users
# mount /dev/design/users /mnt/design/users
          

There is a new group of users "design" to add to the system. One way of dealing with this is to create a new volume group to hold their data. There are no new disks but there is plenty of free space on the existing disks that can be reallocated.

# pvscan 
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/sda"  of VG "dev"   [1.95 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdb"  of VG "sales" [1.95 GB / 1.27 GB free]
pvscan -- ACTIVE   PV "/dev/sdc"  of VG "ops"   [1.95 GB / 564 MB free]
pvscan -- ACTIVE   PV "/dev/sdd"  of VG "dev"   [1.95 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sde"  of VG "ops"   [1.95 GB / 1.9 GB free]
pvscan -- ACTIVE   PV "/dev/sdf"  of VG "dev"   [1.95 GB / 1.33 GB free]
pvscan -- ACTIVE   PV "/dev/sdg1" of VG "ops"   [996 MB / 432 MB free]
pvscan -- ACTIVE   PV "/dev/sdg2" of VG "dev"   [996 MB / 632 MB free]
pvscan -- total: 8 [13.67 GB] / in use: 8 [13.67 GB] / in no VG: 0 [0]
          

# pvmove /dev/sdg1 /dev/sde
pvmove -- moving physical extents in active volume group "ops"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- doing automatic backup of volume group "ops"
pvmove -- 141 extents of physical volume "/dev/sdg1" successfully moved

# pvmove /dev/sdg2 /dev/sdf
pvmove -- moving physical extents in active volume group "dev"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- doing automatic backup of volume group "dev"
pvmove -- 91 extents of physical volume "/dev/sdg2" successfully moved
          

# vgsplit dev design /dev/sdg2
vgsplit -- doing automatic backup of volume group "dev"
vgsplit -- doing automatic backup of volume group "design"
vgsplit -- volume group "dev" successfully split into "dev" and "design"
          

# vgreduce ops /dev/sdg1
vgreduce -- doing automatic backup of volume group "ops"
vgreduce -- volume group "ops" successfully reduced by physical volume:
vgreduce -- /dev/sdg1

# vgextend design /dev/sdg1
vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
vgextend -- doing automatic backup of volume group "design"
vgextend -- volume group "design" successfully extended
          

# lvcreate -L750M -n users design
lvcreate -- rounding up size to physical extent boundary "752 MB"
lvcreate -- doing automatic backup of "design"
lvcreate -- logical volume "/dev/design/users" successfully created
          

# mke2fs /dev/design/users
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
96384 inodes, 192512 blocks
9625 blocks (5.00<!-- ) reserved for the super user
First data block=0
6 block groups
32768 blocks per group, 32768 fragments per group
16064 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840

Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done
        

# mkdir -p /mnt/design/users mount /dev/design/users /mnt/design/users/
        

/dev/design/user
/mnt/design/users   ext2    defaults        1 2
          

In this example the whole system was installed in a single root partition with the exception of /boot. The system had a 2 gig disk partitioned as:

/dev/hda1  /boot 
/dev/hda2  swap
/dev/hda3  /
        

The / partition covered all of the disk not used by /boot and swap. An important prerequisite of this procedure is that the root partition is less that half full (so that a copy of it can be created in a logical volume). If this is not the case then a second disk drive should be used. The procedure in that case is similar but there is no need to shrink the existing root partition and /dev/hda4 should be replaced with (eg) /dev/hdb1 in the examples.

To do this it is easiest to use GNU parted. This software allows you to grow and shrink partitions that contain filesystems. It is possible to use resize2fs and fdisk to do this but GNU parted makes it much less prone to error. It may be included in your distribution, if not you can download it from ftp://ftp.gnu.org/pub/gnu/parted.

Once you have parted on your system AND YOU HAVE BACKED THE SYSTEM UP:

# parted /dev/hda
(parted) p
.
.
.
          

(parted) resize 3 145 999
          

(parted) mkpart primary ext2 1000 1999
          

(parted) q
          

# fdisk /dev/hda
Command (m for help): t
Partition number (1-4): 4
Hex code (type L to list codes): 8e
Changed system type of partition 4 to 8e (Unknown)
Command (m for help): w
          

# mke2fs /dev/vg/root
# mount /dev/vg/root /mnt/
# find / -xdev | cpio -pvmd /mnt
          

  /dev/hda3       /    ext2       defaults 1 1
          

  /dev/vg/root    /    ext2       defaults 1 1
          

# lvmcreate_initrd
        

  image   = /boot/KERNEL_IMAGE_NAME
  label   = lvm
  root    = /dev/vg/root
  initrd  = /boot/INITRD_IMAGE_NAME
  ramdisk = 8192
          

lvmcreate_initrd -- making loopback file (6189 kB)
          

# cp /etc/lilo.conf /mnt/etc/
          

# lilo
        

default=lvm
          

# fdisk /dev/hda

Command (m for help): t
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Unknown)
Command (m for help): w
          

# pvcreate /dev/hda3
# vgextend vg /dev/hda3
          

If you get the warning "incorrect metadata area header checksum" or something about not being able to find PV with UUID foo, you probably toasted the volume group descriptor area and lvm startup can't occur.

Extract the exact uuid for the PV that was overwritten from the file /etc/lvm/archive/VolumeGroupName_XXXXX.vg. (Where XXXXX represents the number of the last known good archived lvm metadata).

Use pvcreate to restore the metadata: pvcreate --uuid "<some_long_string>" --restorefile /etc/lvm/archive/VolumeGroupName_XXXXX.vg <PhysicalVolume>

If you are lucky you'll find that the on-disk lvm metadata takes at least so much space as what it was overwritten with. The above command has been know to recover a PV overwritten with mkswap. If whatever overwrote the VGDA writes past that area, LVs may be affected. In this case, fsck might be able to fix the filesystem on the LV, or you may need more drastic measures to pull data off of it. Contact your local friendly filesystem expert for help in that case.