| Matthew Rosewarne on 18 Aug 2008 07:30:49 -0700 |
|
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:
(technology)
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).
(analogy)
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.
(technology)
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
preserved.
(analogy)
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:
http://tldp.org/HOWTO/LVM-HOWTO/anatomy.html
There's also a fairly comprehensive explanation of LVM from DeveloperWorks.
http://www.ibm.com/developerworks/linux/library/l-lvm/
Attachment:
signature.asc ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|