Logical Volume Management: How PVs form VGs for LVs
Posted by zjem on Tue 22 Apr 2008 at 16:19
When I set out to build my first system using Logical Volume Management I was surprised by the lack of information about how LVM relates to more "traditional" disk-level partitioning. There were plenty of articles with examples of how to use 'vgcreate' and 'lvresize' and no short supply of advice and white noise from the forums, but there was very little practical information about what the various strata of LVM were actually for or how they related to each other. In fact I was well into my search for information before I figured out where to put the file system.
I decided to write this article not as a how-to but as an introduction for anyone who is familiar with the how and why of traditional disk partitioning schemes but is new to Logical Volume Management.
What is Logical Volume Management..?
LVM is simply an additional abstraction layer between the physical storage medium and your data that makes system design and administrative changes easier once the file system is in use.
Wow, that was incredibly concise and well worded, you must be very well paid! Now, what is Logical Volume Management..?
The foundation of Logical Volume Management is the "Physical Volume". Physical Volumes match up 1-to-1 with existing disk-level partitions. Just like "traditional" partitions a physical disk can have multiple Physical Volumes but Physical Volumes can not exceed the maximum size of the disk they occupy. Unlike a traditional partition a Physical Volume is not formatted with a file system, it is just there to support a Volume Group.
Volume Groups are composed of one or more Physical Volumes. Even if you have only one disk and create only one disk-level partition resulting in a single Physical Volume you still must create a Volume Group composed of that single volume. Physical Volumes can be added to and removed from Volume Groups but Volume Groups can not be resized arbitrarily, they are the sum of their underlying Physical Volumes. It is with Volume Groups that you get your first real layer of abstraction from the physical disk, you can have multiple Volume Groups on a single physical disk or multiple physical disks in a single Volume Group.
Logical Volumes are the functional equivalent of disk-level partitions, they are where the file system and your data reside. Logical Volumes are created within Volume Groups similar to the way that traditional partitions are created on physical disks. There is nothing to say that a Logical Volume can't consume an entire Volume Group, and Logical Volumes from multiple Volume Groups can be joined in a single directory structure but a single Logical Volume can not span multiple Volume Groups.
In summary, an LVM partitioning scheme is created by...
- Creating one or more disk-level partitions per physical disk.
- Assigning Physical Volumes to disk-level partitions.
- Joining Physical Volumes in one or more Volume Groups.
- Creating Logical Volumes within the Volume Group(s).
- Formatting Logical Volumes with the file system of your choice.
A note on RAID...
RAID operates on disk-level partitions and presents the resulting usable space as a single "device". The "RAID device" resides below LVM and can be assigned a Physical Volume just like a disk-level partition.
I hope this has reduced and not increased the mystery surrounding this very useful administrative tool. -Joe
[ Parent | Reply to this comment ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
A general comment conc. the first paragraph: pretty much everything in OSS suffers from what I call 'feature oriented' documentation.
Try searching online for info on , say, SELinux, or mutt, LVM or anything else. You'll find a lot of articles explaining all the little features, you'll find man pages of obscure commands, but you rarely will find THE BIG PICTURE. All the documentation is 'feature oriented' i.e. is a long manual describing all the low-level features of the system in question. I - and I suspect I am not alone here - very much prefer 'task oriented' manuals: concise info about how to do a particular thing with the system and WHY would I want to do it this way ( advantages over old system this one is replacing ).
Here's a reason why 'task oriented' is better. Study case: LVM.
Say a user is installing Debian for the first time and the partitioner offers him a choice: old-school partitioning or LVM. The user knows how he would like the system to preform, but he doesn't know if LVM or traditional partitions are better for his needs. He knows the ends, but doesn't know the means.
So he does a search online on LVM and what does he find? A lot of low-level info how to resize, mirror, backup and whatnot. But that is all worthless! What he would like to find is a concise document explaining the differences between partitioning and LVM, and a 'task oriented' manual so he can see what is possible with LVM.
That will get him started. When he is into it already and wants to do something more advanced which is not covered by the concise 'task oriented' manual, he probably already feels the system well enough to figure out the details himself.
With the 'feature oriented' manuals one often has to read the whole damn 300 page manual to figure out if the system in question is even able to do what one needs!
[ Parent | Reply to this comment ]
In computer storage, logical volume management or LVM is a method of allocating space on mass storage devices that is more flexible than conventional partitioning schemes. In particular, a volume manager can concatenate, stripe together or otherwise combine partitions into larger virtual ones that can be resized or moved, possibly while it is being used.which at least satisfies the "why" of LVM, even in the first sentence.
[ Parent | Reply to this comment ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
Ok, maybe with LVM it indeed is not that bad. But my point still stands.
Exercise for the reader: I would like to extract frame no. 3000 of my xvid-encoded stream and save it as a jpeg picture. Can I do it with MPlayer?
Type 'man mplayer' and tell me.
[ Parent | Reply to this comment ]
if this article was a comment on slashdot, i would moderate it "redundant". if this comment was on slashdot, i might moderate it as "flamebait".
one document is sufficient for LVM: the "LVM HOWTO".
it describes "logical volume management", the benefits of LVM on both large and small systems, introduces the components of LVM (PV, VG, LV, etc), gives example command-line usage, and even has "recipes" (series of commands to perform complex, but common, tasks).
maybe this complaint about LVM was warranted in 2002 when i used woody to create a root-on-lvm setup (which required installing a "base" system to a small partition, partitioning the rest of the drive, creating desired PVs, VGs, & LVs, formating LVs, copying parts of the "base" system to the proper LVs, praying & rebooting). now even the infamous debian installer handles it. back then you had to inevitably hand-tweak some mkinitrd script posted by another user of your distro to the LVM mailing list; none of this hold-your-hand-do-it-all-for-you mkinitramfs. okay, enough of the "old man" talk.
about mplayer's man page: the problem there isn't lack of information, but too much information. search the man page long enough for "jpeg" and you'll find an entry under "video output drivers" about JPEG that says "Output each frame into a JPEG file in the current directory." so next i need to find the option to specify a frame. searching for "frame" i eventually stumble upon the "-frames" option, but since that only specifies how many frames to decode, i need to tell it where to start. searching for "start" didn't turn up anything, so i try "seek" (because skipping through a media file, which is what i want mplayer to do to get to the desired frame, is called "seeking"). searching for "seek" i found the "-ss" option which is time based, but how many users measure absolute position within a media stream in frames instead of time, so its good enough for me (and i can always have mplayer seek to a particular time and dump several frames with the previously discovered "-frames" option. if you really want the 3000th frame, then use "-frames 3000" and delete the first 2999 JPEG files.
or you can just search for "mplayer output image frame" (a keyword abbreviation of "i want mplayer to output an image from a frame") with a hit in the top 10 that mentions what i want but using a .net wrapper. i refine my searching using vocabulary from that page ("mplayer extract frame") and the first hit does what i want (but using time-offsets, not frame-offsets, which further reinforces what i previously said).
either method required about 10 minutes of searching and reading. it took me longer to repeat and document the process here than to actually execute it the first time (which probably explains why free software developers have an aversion to writing documentation ;-).
maybe 10 years ago complaining about documentation on common free software was valid, but now the community is so large that just about anything i want to know or do i can find in project websites, wikipedia, blogs, forums, or mailing list archives using google (and maybe a little search kung-fu).
this brings me to a funny realization: people think of the linux early adopters as "hackers", and "hackers" are characterized as being anti-social, but in the early days you had to interact with people (mailing lists, irc, usenet, user groups) to learn anything. now days you can learn linux while truly being anti-social, needing only to interact with google, due to the wealth of online material.
[ Parent | Reply to this comment ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
The problem, which 'man mplayer' is a particular good illustration of, is 'feature-oriented' documentation which is worthless for beginners.
[ Parent | Reply to this comment ]
Not at all. The problem, which the previous poster is a particular good illustration of, is that "man mplayer" is *not* the problem, but the "beginners" unability to properly use google. A secondary problem is the "beginners" tendency to do "something" while lacking the minimal abilities about what such "something" is all about.
I'll won't go into if that's a good or a bad thing but the case is that just ten years ago "extracting a frame from a film" (for a wide definition of "film") was what professionals were for. Definetly a professional, knowing exactly what was trying to do and with a bit of abiliy about "googling", would fastly find his way for the proper documentation since all that he would need is a fast path about the exact way a given program will do what he knows has to be done, while a "beginner", as your posts clearly demonstrate will not only need to find "how to extract a frame from an mpeg" but what are the minimal basis, common jargon and well known practices about that business.
And then, it comes it's all about pedagogy: I find a book much better for self teaching than a random path by Google since the latter won't tell you how much you ignore about the realm you are walking into (as it's clearly demonstrated i.e. by the vast ammount of windows "administrators" able to do "something" just because it's all about clicking here and there and that "something" resulting in great inefficencies and security risks just because they didn't know better about the consecuencies and collateral effects of the "something" their clicking opened).
[ Parent | Reply to this comment ]
Internet search becomes less and less effective as more forums and blogs pop up using technical terms as keywords and making brief reference to them without context. Find-ability ultimately boils down to search ratings and the most clear and thorough Linux documentation ever written would easily get bumped down the search ladder if an Anna Nichole Smith blogger said 'Linux r0x0rz' in one of their posts.
Perhaps the answer is a single definitive source of information where everyone can contribute under the scrutiny of their peers... wait a minute... we could call it Debian Administration, and people could submit articles.
I think the above article has several commendable qualities as far as laymen web documentation goes; it declares it's intent and audience in the first few lines so those seeking something else can return to their search results, and it gives a good general introduction for the intended audience. Perhaps the author or all authors of similar works could better use their time to contribute to man or info pages, but if nothing else this article has drawn traffic and provided a place for multiple links to Steve's more comprehensive article increasing his googlebility. Take that Anna Nichole bloggers!
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
A general reply. I agree.
I'd like to think that my introduction to LVM is more task-orientated. But moving away from being specific LVM issues, user orientated documentation is both the preferable form and the hardest to write.
[ Parent | Reply to this comment ]
Actually RAID need not to reside below the LVM structure. It is possible to shape the system to build a RAID on top of an underlying LVM structure. Whether this is better than the other way round, is arguable (and indeed argued). You will also find people wondering if the two systems, LVM and RAID, could be profitably merged, as they perform similar tasks (although with different goals).
[ Parent | Reply to this comment ]
Any advice on the best way to get expandable RAID 5?
[ Parent | Reply to this comment ]
When learning LVM one of the boundaries that is hard to get around in your head is the physical and logical elements of LVM and what they actually mean.
"Physical Volumes match up 1-to-1 with existing disk-level partitions"
Not the case, a PV is exactly that, a tangible disk (/dev/sda etc). Not a partition of a PV
With LVM the PV is divided into partitions the size of the Physical Extent of the Volume Group it belongs to (64MB, 128MB etc..). You then create Logical Volumes using up a number of Partitions. Then create your filesystem on the LV.
For example, A VG with a PE size of 128MB. You want to create a LV and Fileystem with a size of 2GB.
You would need 16 Partitions allocated to the LV to do this.
2048MB (size of LV/FS) / 128 (PE size of 128MB)
= 16 Partitions needed
"you can have multiple Volume Groups on a single physical disk"
Nope. A whole disk must belong to one VG, no exceptions that I am aware of.
"Logical Volumes are the functional equivalent of disk-level partitions"
Again LV's are made up of many partitions. Functionally similar but for correctness different.
[ Parent | Reply to this comment ]
I'll clean it up whenever I replace that drive. So it may or may not make sense, but you certainly CAN use partitions as PVs, which means that you CAN have multiple VGs on a drive.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Several of my above assertion about the relationship between traditional disk-level partitions were the result of my first creating RAID devices on all of my previous systems. Due to historical limitations with GRUB booting from LVM and RAID I always partitioned my physical drives and then created RAID devices from the non-boot partitions. This led me to believe that LVM was acting on the partitions that constituted the raid devices.
It appears that all of the above comments are correct and I hope that I can find a way to edit the article to incorporate all of the valuable feedback that I have received. However, failing that, I will try to return to the subject of Logical Volume Management in a clearer, more complete (and hopefully more accurate) future article.
-Joe
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I also have learned that its always wise to partition a new disk that is to be allocated for a LVM PV. By giving it one primary partition, You reduce the risk that later taking disk as free in another machine and OS. By also give the partition the type (Linux LVM = 8E) its easier to identify as part of a LVM. One can of course always check with file -s /dev/sda1 (-s for block or character special file as in this case) but as told above if inserted in a Windows server its nice to have the LVM partition type.
But the case where Logical Volumes from multiple Volume Groups can be joined in a single directory structure I dont understand, can You please elaborate ?
[ Parent | Reply to this comment ]