LVM is what partitioning always wanted to be when it grew up. I strongly recomment that people use LVM instead of partitioning. But remember: both partitioning and LVM effect the layering of a crude filesystem below your "real" filesystems. (yet another layer) So sometimes you might want to use neither (neither LVM nor partn).
WARNING: Do not try to use "whole disk" of a CDL volume. I will omit the details here for now. Just don't do it. But if you are on "LDL" (as it is called), or on FBA or SAN or EDEV, then you can safely use "whole disk" and not partition. In fact, it makes a lot of sense to feed SAN LUNs directly into your LVM as PVs and not partition them (and not use "the first partition" as the PV but use the whole disk as the PV). In English, run 'pvcreate' on "whole disk" if SAN (or FBA or EDEV or even LDL). Rob was commenting about the added code path length for swap space carved out of a volume group: > My understanding is that the file on LVM consists of blocks that are > mapped by yet another layer. So your code path to read and write the > blocks gets longer. When the CPU is very fast and I/O is very slow, > this is probably not relevant because any code path is short compared > to the I/O response, and the CPU would be wasted waiting for the I/O > anyway. But when that difference is smaller and unused CPU is not > wasted, it may make sense to review such things. Your understanding, sir, is quite correct. So in any shared context (notably on virtual systems) people should think twice before using a logical volume for swap. On stand-alone systems, logical volume swap is appealing because you can grow a swap volume so easily and you probably will want to grow that swap disk. (In any case, you'll be adding more and then possibly taking some away, whether multiple swap vols or less vols but using LVM.) It may be worth the cost of that extra layer overhead to make the swap vol growable, even if it is a CPU- bound or shared system. (But if there is a hypervisor supporting it, then it makes more sense to pass the volume management to the hypervisor and not do LVM for swap.) For non-swap (that is, for ordinary filesystems) again it might make sense to let the hypervisor manage your vols. On z/VM we're talking minidisks, of course, and as long as they're not CDL you get a lot of mileage from relegating volume management to the CP Directory. (This is why EDEV gets me so geeked out: you can slice up SAN vols as easily as 3370s or 3390s. Aahhhhhh...) These comments should apply equally to z/VM, KVM, Xen, VMware ... etcetera. -- R; <>< ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
