Logical Volume Manager HOWTO
bert hubert <
[email protected]>
Richard Allen <
[email protected]>
Version 0.0.2 $Date: 2000/04/28 01:27:32 $
A very hands-on HOWTO for Linux LVM
______________________________________________________________________
Table of Contents
1. Introduction
1.1 Disclaimer & License
1.2 Prior knowledge
1.3 Housekeeping notes
1.4 Access, CVS & submitting updates
1.5 Layout of this document
2. What is LVM?
3. Basic principles
3.1 Show & Tell
3.2 Active and Inactive: kernel space and user space
4. Prerequisites
4.1 Kernel
4.1.1 Linux 2.4
4.1.2 Linux 2.3.99.*
4.1.3 Linux 2.2
4.1.4 Linux 2.3
4.2 Userspace
5. Growing your filesystem
5.1 With e2fsadm
5.2 Growing your Logical Volume
5.3 Growing your Volume Group
5.4 Growing your filesystem
5.4.1 ext2 off-line with ext2resize
5.4.2 ext2 on-line
6. Replacing disks
6.1 When it's too late
7. Making snapshots for consistent backups
7.1 How does it work?
8. Redundancy & Performance
8.1 Why stripe?
8.2 Why not
8.3 LVM native striping
8.3.1 Performance notices
8.4 Hardware RAID
8.5 Linux software RAID
9. Cookbook
9.1 Moving LVM disks between computers
9.2 Rebuilding /etc/lvmtab and /etc/lvmtab.d
10. Further reading
11. Acknowledgements & Thanks to
______________________________________________________________________
1. Introduction
Welcome, gentle reader.
This document is written to help enlighten you on what LVM is, how it
works, and how you can use it to make your life easier. While there is
an LVM FAQ, and even a German HOWTO, this document is written from a
different perspective. It is a true 'HOWTO' in that it is very hands-
on, while also imparting understanding (hopefully).
I should make it clear that I am not an author of the Linux Logical
Volume Manager. I have great respect for the people who are, and hope
to be able to cooperate with them.
It's even weirder, I don't even know the developers of LVM. I hope
this will change soon. I apologise in advance for stepping on peoples
toes.
1.1. Disclaimer & License
This document is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
If your disks melt and your company fires you - it's never our fault.
Sorry. Make frequent backups and do your experiments on non-mission
critical systems.
Furthermore, Richard Allen does not speak for his employer.
Linux is a registered trademark of Linus Torvalds.
1.2. Prior knowledge
Not much. If you have ever installed Linux and made a filesystem
(fdisk/mkfs), you should be all set. As always when operating as
root, caution is advised. Incorrect commands or any operation on
device files may damage your existing data.
If you know how to configure HP/UX LVM you are almost done, Linux
works almost exactly like the HP implementation.
1.3. Housekeeping notes
There are several things which should be noted about this document.
While I wrote most of it, I really don't want it to stay that way. I
am a strong believer in Open Source, so I encourage you to send
feedback, updates, patches etcetera. Do not hesitate to inform us of
typos or plain old errors.
If you feel to you are better qualified to maintain a section, or
think that you can author and maintain new sections, you are welcome
to do so. The SGML of this HOWTO is available via CVS. I envision
this being a collaborative project.
In aid of this, you will find lots of FIXME notices. Patches are
always welcome! Wherever you find a FIXME, you should know that you
are treading unknown territory. This is not to say that there are no
errors elsewhere, but be extra careful. If you have validated
something, please let us know so I can remove the FIXME notice.
1.4. Access, CVS & submitting updates
The canonical location for the HOWTO is
http://www.ds9a.nl/lvm-howto/
<
http://www.ds9a.nl/lvm-howto/>.
We now have anonymous CVS access available for the world at large.
This allows you to easily obtain the latest version of this HOWTO and
to provide your changes and enhancements.
If you want to grab a copy of the HOWTO via CVS, here is how to do so:
$ export CVSROOT=:pserver:
[email protected]:/var/cvsroot
$ cvs login
CVS password: [enter 'cvs' (without 's)]
$ cvs co lvm-howto
cvs server: Updating lvm-howto
U lvm-howto/lvm-howto.sgml
If you spot an error, or want to add something, just fix it locally,
and run "cvs diff -u", and send the result off to us.
A Makefile is supplied which should help you create postscript, dvi,
pdf, html and plain text. You may need to install sgml-tools,
ghostscript and tetex to get all formats.
1.5. Layout of this document
We will initially be explaining some basic stuff which is needed to do
things. We do try however to include examples where this would aid
comprehension.
2. What is LVM?
Historically, a partition size is static. This requires a system
installer to have to consider not the question of "how much data will
I store on this partition", but rather "how much data will I *EVER*
store on this partition". When a user runs out of space on a
partition, they either have to re-partition (which may involve an
entire operating system reload) or use kludges such as symbolic links.
The notion that a partition was a sequential series of blocks on a
physical disc has since evolved. Most Unix-like systems now have the
ability to break up physical discs into some number of units. Storage
units from multiple drives can be pooled into a "logical volume",
where they can be allocated to partitions. Additionally, units can be
added or removed from partitions as space requirements change.
This is the basis of a Logical Volume Manager (LVM).
For example, say that you have a 1GB disc and you create the "/home"
partition using 600MB. Imagine that you run out of space and decide
that you need 1GB in "/home". Using the old notion of partitions,
you'd have to have another drive at least 1GB in size. You could then
add the disc, create a new /home, and copy the existing data over.
However, with an LVM setup, you could simply add a 400MB (or larger)
disc, and add it's storage units to the "/home" partition. Other
tools allow you to resize an existing file-system, so you simply
resize it to take advantage of the larger partition size and you're
back in business.
As a very special treat, LVM can even make 'snapshots' of itself which
enable you to make backups of a non-moving target. We return to this
exciting possibility, which has lots of other real-world applications,
later on.
In the next section we explain the basics of LVM, and the multitude of
abstractions it uses.
3. Basic principles
Ok, don't let this scare you off, but LVM comes with a lot of jargon
which you should understand lest you endanger your filesystems.
We start at the bottom, more or less.
The physical media
You should take the word 'physical' with a grain of salt, though
we will initially assume it to be a simple hard disk, or a
partition. Examples, /dev/hda, /dev/hda6, /dev/sda. You can turn
any consecutive number of blocks on a block device into a ...
Physical Volume (PV)
A PV is nothing more than a physical medium with some
administrative data added to it - once you have added this, LVM
will recognise it as a holder of ...
Physical Extents (PE)
Physical Extents are like really big blocks, often with a size
of megabytes. PEs can be assigned to a...
Volume Group
A VG is made up of a number of Physical Extents (which may have
come from multiple Physical Volumes or hard drives). While it
may be tempting to think of a VG as being made up of several
hard drives (/dev/hda and /dev/sda for example), it's more
accurate to say that it contains PEs which are provided by these
hard drives.
>From this Volume Group, PEs can be assigned to a ...
Logical Volume (LV)
Yes, we're finally getting somewhere. A Logical Volume is the
end result of our work, and it's there that we store our
information. This is equivalent to the historic idea of
partitions.
As with a regular partition, on this Logical Volume you would
typically build a ...
Filesystem
This filesystem is whatever you want it to be: the standard
ext2, ReiserFS, NWFS, XFS, JFX, NTFS, etc... To the linux
kernel, there is no difference between a regular partition and a
Logical Volume.
I've attempted some ASCII art which may help you visualise this.
A Physical Volume, containing Physical Extents:
+-----[ Physical Volume ]------+
| PE | PE | PE | PE | PE | PE |
+------------------------------+
A Volume Group, containing 2 Physical Volumes (PVs) with 6 Physical Extents:
+------[ Volume Group ]-----------------+
| +--[PV]--------+ +--[PV]---------+ |
| | PE | PE | PE | | PE | PE | PE | |
| +--------------+ +---------------+ |
+---------------------------------------+
We now further expand this:
+------[ Volume Group ]-----------------+
| +--[PV]--------+ +--[PV]---------+ |
| | PE | PE | PE | | PE | PE | PE | |
| +--+---+---+---+ +-+----+----+---+ |
| | | | +-----/ | | |
| | | | | | | |
| +-+---+---+-+ +----+----+--+ |
| | Logical | | Logical | |
| | Volume | | Volume | |
| | | | | |
| | /home | | /var | |
| +-----------+ +------------+ |
+---------------------------------------+
This shows us two filesystems, spanning two disks. The /home
filesystem contains 4 Physical Extents, the /var filesystem 2.
bert hubert is writing a tool <
http://ds9a.nl/lvm-viewer> to represent
LVM more visually, a screenshot <
http://ds9a.nl/lvm-
howto/screenshot.gif> is provided. Looks better than the ASCII art.
3.1. Show & Tell
Ok, this stuff is hard to assimilate ('We are LVM of Borg...'), so
here is a very annotated example of creating a Logical Volume. Do NOT
paste this example onto your console because you WILL destroy data,
unless it happens that on your computer /dev/hda3 and /dev/hdb2 aren't
used.
When in doubt, view the ASCIIgram above.
You should first set the partition types of /dev/hda3 and /dev/hdb2 to
0x8e, which is 'Linux LVM'. Please note that your version of fdisk may
not yet know this type, so it will be listed as 'Unknown':
# fdisk /dev/hda
Command (m for help): p
Disk /dev/hda: 255 heads, 63 sectors, 623 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 2 16033+ 83 Linux
/dev/hda2 3 600 4803435 83 Linux
/dev/hda3 601 607 56227+ 83 Linux
/dev/hda4 608 614 56227+ 83 Linux
Command (m for help): t
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Command (m for help): p
Disk /dev/hda: 255 heads, 63 sectors, 623 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 2 16033+ 83 Linux
/dev/hda2 3 600 4803435 83 Linux
/dev/hda3 601 607 56227+ 8e Unknown
/dev/hda4 608 614 56227+ 83 Linux
Command (m for help): w
We do the same for /dev/hdb2, but we don't display it here. This is
needed so that LVM is able to reconstruct things should you lose your
configuration.
Now, this shouldn't be necessary, but some computers require a reboot
at this point. So if the following examples don't work, try rebooting.
We then create our Physical Volumes, like this:
# pvcreate /dev/hda3
pvcreate -- physical volume "/dev/hda3" successfully created
# pvcreate /dev/hdb2
pvcreate -- physical volume "/dev/hdb2" successfully created
We than add these two PVs to a Volume Group called 'test':
# vgcreate test /dev/hdb2 /dev/hda3
vgcreate -- INFO: using default physical extent size 4 MB
vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
vgcreate -- doing automatic backup of volume group "test"
vgcreate -- volume group "test" successfully created and activated
So we now have an empty Volume Group, let's examine it a bit:
# vgdisplay -v test
--- Volume group ---
VG Name test
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 0
Open LV 0
MAX LV Size 255.99 GB
Max PV 256
Cur PV 2
Act PV 2
VG Size 184 MB
PE Size 4 MB
Total PE 46
Alloc PE / Size 0 / 0
Free PE / Size 46 / 184 MB
--- No logical volumes defined in test ---
--- Physical volumes ---
PV Name (#) /dev/hda3 (2)
PV Status available / allocatable
Total PE / Free PE 13 / 13
PV Name (#) /dev/hdb2 (1)
PV Status available / allocatable
Total PE / Free PE 33 / 33
Lots of data here - most of it should be understandable by now. We see
that there are no Logical Volumes defined, so we should work to remedy
that. We try to generate a 50 megabyte volume called 'HOWTO' in the
Volume Group 'test':
# lvcreate -L 50M -n HOWTO test
lvcreate -- rounding up size to physical extent boundary "52 MB"
lvcreate -- doing automatic backup of "test"
lvcreate -- logical volume "/dev/test/HOWTO" successfully created
Ok, we're nearly there, let's make a filesystem:
# mke2fs /dev/test/HOWTO
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
13328 inodes, 53248 blocks
2662 blocks (5.00%) reserved for the super user
First data block=1
7 block groups
8192 blocks per group, 8192 fragments per group
1904 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
# mount /dev/test/HOWTO /mnt
# ls /mnt
lost+found
And we're done! Let's review our Volume Group, because it should be
filled up a bit by now:
# vgdisplay test -v
--- Volume group ---
VG Name test
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 1
Open LV 1
MAX LV Size 255.99 GB
Max PV 256
Cur PV 2
Act PV 2
VG Size 184 MB
PE Size 4 MB
Total PE 46
Alloc PE / Size 13 / 52 MB
Free PE / Size 33 / 132 MB
--- Logical volume ---
LV Name /dev/test/HOWTO
VG Name test
LV Write Access read/write
LV Status available
LV # 1
# open 1
LV Size 52 MB
Current LE 13
Allocated LE 13
Allocation next free
Read ahead sectors 120
Block device 58:0
--- Physical volumes ---
PV Name (#) /dev/hda3 (2)
PV Status available / allocatable
Total PE / Free PE 13 / 13
PV Name (#) /dev/hdb2 (1)
PV Status available / allocatable
Total PE / Free PE 33 / 20
Well, it is. /dev/hda3 is completely unused, but /dev/hdb2 has 13
Physical Extents in use.
3.2. Active and Inactive: kernel space and user space
As with all decent operating systems, Linux is divided in two parts:
kernel space and user space. Userspace is sometimes called userland,
which would also be a good name for a theme park, 'Userland'.
Discovery, creation and modification of things pertaining to Logical
Volume Management is done in user space, and then communicated to the
kernel. Once a volume group or logical volume is reported to the
kernel, it is called 'Active'. Certain changes can only be performed
when an entity is active, others only when it is not.
4. Prerequisites
There is a wide range of kernels where LVM is available on. In Linux
2.4, LVM will be fully integrated. From kernel 2.3.47 and onwards, LVM
is in the process of being merged into the main kernel.
4.1. Kernel
4.1.1. Linux 2.4
Will contain everything you need. It is expected that most
distributions will release with LVM included as a module. If you need
to compile, just tick off the LVM option when selecting your block
devices.
4.1.2. Linux 2.3.99.*
Once things have calmed down on the kernel development front, this
section will vanish. For now, the gory details.
As we write this, Linux 2.3.99pre5 is current and it still needs a
very tiny patch to get LVM working.
For Linux 2.3.99pre3, two patches were released:
The patch was posted on linux-kernel, and is available here
<
http://ds9a.nl/lvm-howto/2.3.99pre3>.
Andrea Arcangeli improved on that patch, and supplied an incremental
patch <
http://ds9a.nl/lvm-howto/andrea.patch>, which should be applied
on top of the 2.3.99pre3 LVM patch above.
For Linux 2.3.99pre5, bert hubert rolled these two patches into one
and ported it to 2.3.99pre5. Patch <
http://ds9a.nl/lvm-
howto/2.3.99-pre5.lvm.patch>. Use with care.
2.3.99pre6-1, yes, a prerelease of a prepatch, features for the first
time complete LVM support! It stil misses Andreas patch but we have
been assured that it is in the queue to be released real soon.
2.3.99pre4-ac1 has the tiny LVM patch in by default, and working. It
does not contain Andreas patch though.
4.1.3. Linux 2.2
FIXME: write this
4.1.4. Linux 2.3
FIXME: write this
4.2. Userspace
You need the tools available from the LVM site
<
http://lvm.msede.com/lvm>. Compiling them on glibc2.1 systems
requires a tiny patch, and even then gives errors on Debian 2.2.
5. Growing your filesystem
You can do this with a provided script which does a lot of work for
you, or you can do it by hand if needed.
5.1. With e2fsadm
If there is room within your volume group, and you use the ext2
filesystem (most people do), you can use this handy tool.
The e2fsadm command uses the commercial resize2fs tool. While people
feel that this is good software, it is not very widely installed.
If you want to use the FSF's ext2resize command, you need to inform
e2fsadm of this:
# export E2FSADM_RESIZE_CMD=ext2resize
# export E2FSADM_RESIZE_OPTS=""
The rest is easy, e2fsadm is a lot like the other LVM commands:
# e2fsadm /dev/test/HOWTO -L+50M
e2fsadm -- correcting size 102 MB to physical extent boundary 104 MB
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/test/HOWTO: 11/25688 files (0.0% non-contiguous), 3263/102400 blocks
lvextend -- extending logical volume "/dev/test/howto" to 104 MB
lvextend -- doing automatic backup of volume group "test"
lvextend -- logical volume "/dev/test/HOWTO" successfully extended
ext2_resize_fs
ext2_grow_fs
ext2_block_relocate
ext2_block_relocate_grow
ext2_grow_group
ext2_add_group
ext2_add_group
ext2_add_group
ext2_add_group
ext2_add_group
ext2_add_group
direct hits 4096 indirect hits 0 misses 1
e2fsadm -- ext2fs in logical volume "/dev/test/HOWTO" successfully extended to 104 MB
5.2. Growing your Logical Volume
The e2fsadm command takes care of this for you. However, it may be
useful to understand how to do this manually:
If you have room within your Volume Group, this is a one liner:
# lvextend -L+12M /dev/test/HOWTO
lvextend -- rounding size to physical extent boundary
lvextend -- extending logical volume "/dev/test/HOWTO" to 116 MB
lvextend -- doing automatic backup of volume group "test"
lvextend -- logical volume "/dev/test/HOWTO" successfully extended
5.3. Growing your Volume Group
This is done with the vgextend utility, and is easy as pie. You first
need to create a physical volume. This is done with the pvcreate
utility. With this tool, you convert any block device into a physical
volume.
After that is done, vgextend does the rest:
# pvcreate /dev/sda1
pvcreate -- physical volume "/dev/sda1" successfully created
# vgextend webgroup /dev/sda1
vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
vgextend -- doing automatic backup of volume group "webgroup"
vgextend -- volume group "webgroup" successfully extended
Please note that in order to do this, your Volume Group needs to be
active. You can make it by executing 'vgchange -a y webgroup'.
5.4. Growing your filesystem
If you want to do this manually, there are a couple of ways to do
this.
5.4.1. ext2 off-line with ext2resize
By off-line, we mean that you have to unmount the file-system to make
these changes. The file-system and it's data will be unavailable
while doing this. Note this means you must use other boot media if
extending the size of the root or other important partitions.
The ext2resize tool is available on the GNU ftp size, but most
distributions carry it as a package. The syntax is very
straightforward:
# ext2resize /dev/HOWTO/small 40000
Where 40000 is the number of blocks the filesystem should have after
growing or shrinking.
5.4.2. ext2 on-line
FIXME: write this
6. Replacing disks
This is one of the benefits of LVM. Once you start seeing errors on a
disk, it is high time to move your data. With LVM this is easy as pie.
We first do the obvious replacement example where you add a disk to
the system that's at least as large as the one you want to replace.
To move data, we move Physical Extents of a Volume Group to another
disk, or more precisely, to another Physical Volume. For this, LVM
offers us the pvmove utility.
Let's say that our suspicious disk is called /dev/hda1 and we want to
replace it by /dev/sdb3. We first add /dev/sdb3 to the Volume Group
that contains /dev/hda1.
It appears advisable to unmount any filesystems on this Volume Group
before doing this. Having a full backup might not hurt either.
FIXME: is this necessary?
We then execute pvmove. In its simplest invocation, we just mention
the disk we want to remove, like this:
# pvmove /dev/hda1
pvmove -- moving physical extents in active volume group "test1"
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 "test1"
pvmove -- 12 extents of physical volume "/dev/hda1" successfully moved
Please heed this warning. Also, it appears that at least some kernels
or LVM versions have trouble with this command. I tested it with
2.3.99pre6-2, and it works, but be warned.
Now that /dev/hda1 contains no Physical Extents anymore, we can reduce
it from the Volume Group:
# vgreduce test1 /dev/hda1
vgreduce -- doing automatic backup of volume group "test1"
vgreduce -- volume group "test1" successfully reduced by physical volume:
vgreduce -- /dev/hda1
FIXME: we need clarity on a few things. Should the volume group be
active? When do we get data loss?
6.1. When it's too late
If a disk fails without warning and you are unable to move the
Physical Extents off it to a different Physical Volume you will have
lost data unless the Logical Volumes on the PV that failed was
mirrored. The correct course of action is to replace the failed PV
with an identical one or at least a partition of the same size.
The directory /etc/lvmconf contains backups of the LVM data and
structures that make the disks into Physical Volumes and list which
Volume Groups that PV belongs to and what Logical Volumes are in the
Volume Group.
After replacing the faulty disk you can use the vgcfgrestore command
to recover the LVM data to the new PV. This restores the Volume Group
and all it's info, but it does not restore the data that was in the
Logical Volumes. This is why most LVM commands make backups
automatically of the LVM data when doing changes.
7. Making snapshots for consistent backups
This is one of the more incredible possibilities. Let's say you have a
busy server, with lots of things happening. For a useful backup, you
need to shut down a large number of programs because otherwise you end
up with inconsistencies.
The canonical example is moving a file from /tmp to /root, where /root
was being backed up first. When /root was read, the file wasn't there
yet. By the time /tmp was backed up, the file was gone.
Another story goes for saving databases or directories. We have no
clue if a file is in any usable state unless we give the application
time to do a clean shutdown.
Which is where another problem pops up. We shut down out applications,
make our backup, and restart them again. This is all fine as long as
the backup only takes a few minutes, but gets to be real painful if it
takes hours, or if you're not even sure how long it takes.
LVM to the rescue.
With LVM we can make a snapshot picture of a Logical Volume which is
instantaneous, and then mount that and make a backup of it.
Let's try this out:
# mount /dev/test/HOWTO /mnt
# echo > /mnt/a.test.file
# ls /mnt/
a.test.file lost+found
# ls -l /mnt/
total 13
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file
drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found
Ok, we now have something to work with. Let's make the snapshot:
# lvcreate --size 16m --snapshot --name snap /dev/test/HOWTO
lvcreate -- WARNING: all snapshots will be disabled if more than 16 MB are changed
lvcreate -- INFO: using default snapshot chunk size of 64 KB
lvcreate -- doing automatic backup of "test"
lvcreate -- logical volume "/dev/test/HOWTO" successfully created
More on the '--size' parameter later. Let's mount the snapshot:
# mount /dev/test/snap /snap
# ls /snap
total 13
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file
drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found
Now we erase a.test.file from the original, and check if it's still
there in the snapshot:
# rm /mnt/a.test.file
# ls /snap
total 13
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file
drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found
Amazing Mike!
7.1. How does it work?
Remember that we had to set the '--size' parameter? What really
happens is that the 'snap' volume needs to have a copy of all blocks
or 'chunks' as LVM calls them, which are changed in the original.
When we erased a.test.file, it's inode was removed. This caused 64 KB
to be marked as 'dirty' - and a copy of the original data was written
to the than 16MB of "chunks" are modified, the snapshot will be
deactivated.
To determine the correct size for a snapshot partition, you will have
to guess based on usage patterns of the primary LV, and the amount of
time the snapshot will be active. For example, an hour-long backup in
the middle of the night when nobody is using the system may require
very little space.
Please note that snapshots are not persistent. If you unload LVM or
reboot, they are gone, and need to be recreated.
8. Redundancy & Performance
For performance reasons, it is possible to spread data in a 'stripe'
over multiple disks. This means that block 1 is on Physical Volume A,
and block 2 is on PV B, while block 3 may be on PV A again. You can
also stripe over more than 2 disks.
This arrangement means that your have more disk bandwidth available.
It also means that more 'spindles' are involved. More on this later.
Besides increasing performance, it is also possible to have your data
in copies on multiple disks. This is called mirroring. Currently, LVM
does not support this natively but there are ways to achieve this.
8.1. Why stripe?
Disk performance is influenced by three things, at least. The most
obvious is the speed at which data on a disk can be read or written
sequentially. This is the limiting factor when reading or writing a
large file on a SCSI/IDE bus with only a single disk on it.
Then there is the bandwidth available TO the disk. If you have 7 disks
on a SCSI bus, this may well be less than the writing speed of your
disk itself. If you spend enough money, you can prevent this
bottleneck from being a problem.
Then there is the latency. As the saying goes, latency is always bad
news. And even worse, you can't spend more money to get lower
latency! Most disks these days appear to have a latency somewhere
around 7ms. Then there is the SCSI latency, which used to be something
like 25ms.
FIXME: need recent numbers!
What does this mean? The combined latency would be around 30ms in a
typical case. You can therefore perform only around 33 disk operations
per second. If you want to be able to do many thousands of queries
per second, and you don't have a massive cache, you are very much out
of luck.
If you have multiple disks, or 'spindles', working in parallel, you
can have multiple commands being performed concurrently, which nicely
circumvents your latency problem. Some applications, like a huge news
server, don't even work anymore without striping or other IO
smartness.
This is what striping does. And, if your bus is up to it, even
sequential reading and writing may go faster.
8.2. Why not
Striping without further measures raises your fault chance, on a 'per
bit' basis. If any of your disks dies, your entire Logical Volume is
gone. If you just concatenate data, only part of your filesystem is
gone.
The ultimate option is the mirrored stripe.
FIXME: make a mirrored stripe with LVM and md
8.3. LVM native striping
Specifying stripe configuration is done when creating the Logical
Volume with lvcreate. There are two relevant parameters. With -i we
tell LVM how many Physical Volumes it should use to scatter on.
Striping is not really done on a bit-by-bit basis, but on blocks. With
-I we can specify the granulation in kilobytes. Note that this must be
a power of 2, and that the coarsest granulation is 128Kbyte.
Example:
# lvcreate -n stripedlv -i 2 -I 64 mygroup -L 20M
lvcreate -- rounding 20480 KB to stripe boundary size 24576 KB / 6 PE
lvcreate -- doing automatic backup of "mygroup"
lvcreate -- logical volume "/dev/mygroup/stripedlv" successfully created
8.3.1. Performance notices
The performance 'gain' may well be very negative if you stripe over 2
partitions of the same disk - take care to prevent that. Striping with
two disks on a single IDE bus also appears useless - unless IDE has
improved beyond what I remember.
FIXME: is this still true?
Older motherboards may have two IDE buses, but the second one used to
be castrated, dedicated to serving a slow cdrom drive. You can perform
benchmarks with several tools, the most noteworthy being 'Bonnie'. The
ReiserFS people have released Bonnie++
<
http://www.coker.com.au/bonnie++/> which may be used to measure
performance data.
8.4. Hardware RAID
Many high end Intel x86 servers have Hardware RAID controlers. Most of
them have atleast 2 independant SCSI channels. Fortunatly, his has
very little bearing on LVM. Before Linux can see anything on such a
controler the administrator must define a Logical drive within the
raid controler itself. As an example [s]he could choose to stripe
together two disks on SCSI channel A and then mirror them onto two
disks on channel B. This is a typical RAID 0/1 configuration that
maximises performance and data security. When Linux boots on a machine
with this configuration it can only 'see' one disk on the RAID
controler and that is the Logical drive that contains the four disks
in the RAID 0/1 stripeset. This means, as far as LVM is concerned,
that there is just one disk in the machine and it is to be used as
such. If one of the disks fails, LVM wont even know. When the
administrator replaces the disk (even on the fly with HotSwap
hardware) LVM wont know about that either and the controler will
resync the mirrored data and all will be well. This is where most
people take a step back and ask "Then what good does LVM do for me
with this RAID controler?" The easy answer is, in most cases, after
you define a logical drive in the RAID controler you cant add more
disks to that drive later. So if you miscalculate the space
requirements or you simply need more space you cant add a new disk or
set of disks into a pre-exsisting stripeset. This means you must
create a new RAID stripset in the controler and then with LVM you can
simply extend the LVM Logical volume so that it seamlessly spans both
stripesets in the RAID controler.
FIXME: Is there more needed on this subject ?
8.5. Linux software RAID
Linux 2.4 comes with very good RAID in place. Linux 2.2 by default, as
released by Alan Cox, features an earlier RAID version that's not well
regarded. The reason that 2.2 still features this earlier release is
the the kernel people don't want to make changes within a stable
version that require userland updates.
Most people, which included Red Hat, Mandrake and SuSE, chose to
replace it with the 0.90 version which appears to be excellent.
We will only treat the 0.90 version here.
FIXME: write more of this
9. Cookbook
9.1. Moving LVM disks between computers
With all this new technology, simple tasks like moving disks from one
machine to another can get a bit tricky. Before LVM users only had to
put the disk into the new machine and mount the filesystems. With LVM
there is a bit more to it. The LVM structures are saved both on the
disks and in the /etc/lvmconf directory so the only thing that has to
be done to move a disk or a set of disks that contain a Volume Group
is to make sure the machine that the VG belonged to will not miss it.
That is accomplished with the vgexport command. vgexport simply
removes the structures for the VG from /etc/lvmconf, but does not
change anything on the disks. Once the disks are in the new machine
(they don't have to have the same ID's) the only thing that has to be
done is to update /etc/lvmconf. Thats done with vgimport.
Example:
On machine #1:
vgchange -a n vg01
vgexport vg01
On machine #2:
vgimport vg01 /dev/sda1 /dev/sdb1
vgchange -a y vg01
Notice that you don't have to use the same name for the Volume Group.
If the vgimport command did not save a configuration backup use
vgcfgbackup to do it.
9.2. Rebuilding /etc/lvmtab and /etc/lvmtab.d
FIXME: write about more neat stuff
10. Further reading
LVM site <
http://lvm.msede.com/lvm/>
The main LVM resource available
German LVM HOWTO <
http://litefaden.com/lite00/lvm/>
If you can read German, this already contains a lot of
information
Translation of the German HOWTO <
ftp://linux.msede.com/howto/>
[email protected] is translating the German HOWTO into
English. It appears that they will soon be investing lots of
time in it. If you doubt our HOWTO or miss something, please try
their effort.
HP/UX Managing Disks Guide <
http://docs.hp.com/cgi-
bin/omcgi/omdoc?action=getcon&ID=7425>
Since the Linux LVM is almost an exact workalike of the HP/UX
implementation, their documentation is very useful to us as
well. Very good stuff.
11. Acknowledgements & Thanks to
We try to list everybody here who helped make this HOWTO. This
includes people who send in updates, fixes or contributions, but also
people who have aided our understanding of the subject.
� Axel Boldt <
[email protected]>
� Sean Reifschneider <
[email protected]>
� Alexander Talos <
[email protected]>
� Eric Maryniak <
[email protected]>