Matthew Rosewarne on 18 Aug 2008 07:30:49 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] LVM primer (Formerly: "reinstalling grub")

On Monday 28 July 2008, Art Alexion wrote:
> Part of my problem is not fully understanding LVM.  Is there a good primer
> that you can direct me to?

Sorry for the late reply, I've been busy with Akademy.

The short version:
	Hard disks and most other storage devices are called "block devices" becuase 
data is read/written in "blocks" (usually 512 bytes for HDDs, 2048 for 
CDROMs).  This is different from "character devices", which read/write one 
byte at a time.  Without LVM, the disk is divided into partitions, which are 
specified as a start position (in blocks) and a size (in blocks).
	Imagine writing a novel on a long tickertape.  You need to chop the tape into 
chapters before you've actually written anything.  Hopefully you've left 
enough space for your chapters to fit, since you've already cut up the tape 
and thus can't change any chapter's start position without starting again with 
a fresh tape.

	LVM is an abstraction above disks and partitions.  You designate some block 
devices as "physical volumes" ("PV"s for short).  Instead of writing directly 
to these devices, they are divided into "extents", which are much larger 
chunks of data (4MB by default).  PVs are added to "volume groups" (or "VG"s), 
which tie them together into one big pool of extents.  "Logical volumes" 
("LV"s) are created by allocating a number of extents from the VG.  Using the 
kernel's "device mapper" functionality, LVs show up as just another block 
device, so they can be used just like actual partitions.  When you read/write 
to an LV, the LVM driver uses its metadata to map the virtual blocks on the LV 
to the real blocks on the actual device.
	The fun comes from the ability to simply add or remove extents from the pool, 
letting you resize LVs at will.  You can even do more interesting things like 
striping extents between PVs for a RAID0-like setup, or using "snapshots" 
where changed extents are written using copy-on-write and the original data is 
	Back to the novel, this would be like taking that tickertape and chopping it 
into many smaller pieces and putting them all in a bag.  You reach into the 
bag and grab some pieces to write a chapter.  If this chapter grows too big to 
fit on those pieces, you just grab some more from the bag, and likewise if you 
don't need that many pieces, you put them back in.

Here's an explanation from the LVM HOWTO:

There's also a fairly comprehensive explanation of LVM from DeveloperWorks.

Attachment: signature.asc
Description: This is a digitally signed message part.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --