<!doctype linuxdoc system>

<!-- LinuxDoc file was created by LyX 1.0 (C) 1995-1999 by <pw> Sun Mar  5 01:50:31 2000
 -->

 <manpage>
 <sect1>Beginners Guide to LVM
 <sect1>What is LVM?
 <p>LVM stands for "Logical Volume Manager".
 </p>
 <p>Put in a few words, it is a flexible method to manage your disk space.
 This is a VERY simplistic statement!
 </p>
 <p>Let me take some words more. LVM allows you to overcome the space limitations
 of hard disks. With LVM it is possible to create filesystems spanning more
 than one disk. This is impossible with the partitions schemes currently in
 use on most Linux systems. With LVM and help from its friends MD and reiserfs
 as well as ext2fsadm it is also possible to create and manage efficiently large
 amounts of disk space, create filesystems, mount them, resize them online (extending
 and shrinking), move data pysically from one disk to another without changing
 the position in the file tree and much more. And all this in a convenient manner.
 </p>
 <sect1>Why LVM?
 <p>Why would someone try to do things like these? They seem a little bit crazy,
 at least at the first moment. This might be true if your machine is a typical
 home machine: a box with one or two disks. While there are possibly more home
 machines out there than machines in data centers, the latter ones have special
 software to handle large amounts of disks. Imagine the situation a database
 machine, a seek engine or a portal is facing: large and steadily growing amounts
 of data produced by robots or customers. If they offer some service like news
 or free email they will have enormously growing data sets. Now imagine yourself
 as administrator of such a machine, facing the threat of filesystems constantly
 filling up. Will you catch every filesystem before the dreaded message "could
 not write to disk. Possibly filesystem full." occurs? Even if you were doing
 nothing than partitioning, formatting and adding disks you would hardly keep
 up with your work ... 
 </p>
 <p>Lets say you bought a bunch of those fancy new 72GB disks and put them
 into your ever space hungry server. You might feel safe for a moment, but what
 if a filesystem would grow bigger than that? Previously you had but one choice:
 copy the data out to tape or disk, destroy the file system and create a bigger
 new one, then copy the data back. Of course this problem is not new and there
 have been numerous attempts to solve it: concatenated disks, RAID systems with
 special controllers and so on. But they all complicate the handling of data
 much more than LVM does.
 </p>
 <sect1>Some Basic Concepts
 <p>When booting, the BIOS of a PC looks at the first sector of a disk (the
 Master Boot Record, MBR) and validates that a boot record is found. Then control
 is passed to the boot loader in this structure which in turn reads more blocks
 from the disk, using the BIOS i/o routines. This is the reason for partitioning
 - the BIOS reads the blocks and its routines define the layout of hard disks.
 
 </p>
 <p>Current disks on PCs can be partitioned with primary partitions and additonally
 extended partitions. A minimum of one primary partition is required and a maximum
 of four primary partitions per disk is allowed. As a method to handle disk
 partitions more flexible there is also the option to create one extended partition
 per disk at the cost of losing one primary partition. The extended partition
 itself is unusable for file systems. Instead is used as a container to overcome
 the limitation of primary partitions: within an extended partition logical
 partitions can be created which in turn can be used. The BIOS normally requires
 that at least one primary partition is present which is tagged active and contains
 the OS (This is true at least for older operating systems - Linux as a clever
 OS has a number of boot managers which are able to boot the kernel even from
 logical partitions). Thus, many operating systems tend to configure the disk
 as one partition and use its space for all purposes. 
 </p>
 <p>Not to mention multi-boot configurations, this solution is somewhat suboptimal:
 An operating system has to perform many different tasks, requiring different
 use of resources - disk space in our case. There is e.g. swap as well as storage
 for temporary files, applications, and there can be numerous more, depending
 on the type of system. All of these should be handled spearately, primarily
 to avoid data loss which could occur if there were only one file system and
 this would be damaged but also to gain a finer level of control. Therefore
 often disks are configured with primary and extended partitions, and partitioning
 schemes for various purposes are a part of virtually every Linux installation
 guide. This topic also leads to lengthy debates since all of these schemes
 share a common problem: they can't be changed after installation without massive
 impact on the operating system, usually requiring a fresh installation.
 </p>
 <p>This is where LVM comes into play. It allows to handle disk space very
 flexible not only at installation time but also anytime later. But for this
 we have to adopt some new ideas. Basically the BIOS limitation of four primary
 partitions can't be overcome but in the effect this is what happens. We will
 now have a look at the terms of LVM
 </p>
 <sect2>Physical Volumes
 <p>A Physical Volume (PV) is the basic bulding block. It is a primary partition
 on a disk, usually only one of four possible. It is marked in the partition
 table with the label "<tt></tt><tt><bf>0x8e</bf></tt><bf></bf>" to avoid usage by other operating systems and to
 show that it is something special. One or more (up to 256) Physical Volumes
 form a Volume Group (VG).
 </p>
 <sect2>Volume Groups
 <p>Volume Groups are "containers" of disk space. Any definition of file systems,
 management of disk space and so on is done on their basis. Therefore some more
 informations are needed at this point. Imagine VGs as a pool of disk space,
 or, if you like, as an extensible, huge stock of storage where you don't have
 to buy all of the goods at one time. Insted you buy what you need for your
 daily or weekly subsitsence with exact knowledge of the filling status of the
 stock. As long as there is some storage you can easily "buy" it and give it to
 the storage hungry file systems. And if your stock is running low you can add
 some more storage by adding disk(s) and give it to the file systems without
 the need to stop at a size where a normal disk would be full. Also you can
 react very dynamically to storage needs which weren't foreseeable at the moment
 the machine was set up. Up to 99 VGs are possible per machine.
 </p>
 <sect2>Logical Volumes
 <p>Now, this is the place where we can draw a comparison to the traditional
 storage scheme. Like partitions, Logical Volumes (LV) can contain file systems
 or can be used directly by applications which can handle "raw partitions" like
 databases. A maximum of 256 Logical Volumes can be defined per VG. Logical
 volumes can reside anywhere in a Volume Group, but they can't span the borders
 of a VG. This means, that a LV can be located on one or more disks - in fact,
 on many disks as are in the VG.
 </p>
 <p>The following picture tries to show this:
 </p>
 <sect2>Physical Entries
 <p>To accomplish that goal the way chosen was to cut the PVs to pieces called
 Physical Entries (PE). The size of a PE is specific to the Volume Group, and
 all PVs in a VG have PEs of the same size. The PE size is defined at the creation
 time of a VG and cannot be changed later. PEs can range in size from a few
 KBs up to several GBs. There is no standard size for a PE but a good measure
 is 4 to 8MB. PEs are numbered consequently on a PV, but not in a VG. There
 is a maximum of 65534 PEs per PV.
 </p>
 <sect2>Logical Entries
 <p>Every Logical Entry (LE) is mapped to a Physical Entry. Logical Volumes
 are formed by adding LEs together and mapping them to their respective PEs.
 This way the size of LVs can only be specified in powers of the size of a LE;
 also extensions of an LV are done in powers of an LE, even if only one byte
 more would be needed. LEs are numbered consequently in a LV, but not on a PV
 nor in the VG. Up to 65534 LEs are allowed per LV.
 </p>
 <sect1>O.K., and now?
 <p>To begin to use LVM, you have to have LVM support in your kernel and the
 user space tools compiled and ready for use. There are some Linux distributions
 out there with LVM support already built in, e.g. SuSE6.3 (although that has
 a nasty bug with installation), but if you own an older Linux installation
 chances are that you have to download the sources and install it by yourself.
 LVM is available for 
 </p>


 </manpage>