![]() Notice that “a collection of extents” says nothing about where the extents are coming from and certainly doesn’t impose a fixed limit on the size of a volume group. ![]() The reason LVM splits physical volumes into small, equally sized physical extents is that the definition of a volume group (the space that’ll be carved into logical volumes) then becomes “a collection of physical extents” rather than “a physical area on a physical drive,” as with old-school partitions. If you’re confused about what possible benefit we get from adding all this complexity only to wind up with the same fixed-size partitions in the end, hang in there. It’s the LVs, these virtual partitions, and not the ones on the physical hard drive, that carry a filesystem and are mapped and mounted into the OS. These partitions are now physical volumes (PVs), which are split into physical extents (PEs) and then grouped in volume groups (VGs), on top of which you finally create logical volumes (LVs). You take a physical hard drive and set up one or more partitions on it that will be used for LVM. And behind the scenes, LVM splits up physical volumes into small slabs of bytes (4MB by default), each of which is called a physical extent, or a PE. We create filesystems on these LVs and mount them into our directory tree. We carve those up into logical volumes, or LVs, that act like the normal partitions we’re used to dealing with. We group PVs into volume groups, or VGs, which are virtual storage pools that look like good old cookie-cutter hard drives. Under LVM, physical volumes, or PVs, are seen just as providers of disk space without any inherent organization (such as partitions mapping to a mount point in the OS). Wrapping your head around LVM is a bit more difficult than with RAID because LVM rethinks the whole way of dealing with storage, which expectedly introduces a bit of jargon that you need to learn. LVM has undergone tremendous improvements since then and is widely used in production today, and just as you expect, the Ubuntu installer makes it easy for you to configure it on your server during installation. Through the magic of free software, a guy by the name of Heinz Mauelshagen wrote an implementation of a logical volume manager for Linux in 1998, which we’ll refer to as LVM. LVM has traditionally been a feature of expensive, enterprise Unix operating systems or was available for purchase from third-party vendors. Very cool, and very doable via logical volume management (LVM), a system that shifts the fundamental unit of storage from physical drives to virtual or logical ones. Then we could have partitions that are trivially resizable or that can span multiple drives, we could easily take some space from one partition and tack it on another, and we could juggle partitions around on physical drives on a live server. ![]() What we’d really want is a way to push the partition concept up one level of abstraction, so it doesn’t operate directly on the underlying physical media. It’ll do wonders for your worries about performance and fault tolerance, but it operates at too low a level to help with the partition size or fluidity concerns. This article is excerpted from the newly published book The Offical Ubuntu Book, Third Edition published by Prentice Hall Professional, June 2008, Copyright 2008 Canonical, Ltd. And if you might have to move a partition across physical volume boundaries on a running system, well, woe is you. As if worrying about speed and data loss weren’t enough, you also have to worry about whether your partition size calculations were just right when you were installing a server or whether you’ll wind up in the unenviable position of having a partition run out of space, even though another partition is maybe mostly unused. ![]() Hard drives are slow and fail often, and though abolished for working memory ages ago, fixed-size partitions are still the predominant mode of storage space allocation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |