> Thats the issue we are trying to avoid if possible. If we could put /, > /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how > much disk we'll need from the outset. We could grow as needed.
I guess my first question is "why is / expanding at all?" If you're getting a need for expanding root filesystems, something else is wrong. The case for the other filesystems is fine; I'd agree on putting them in LVM in a second. > I keep reading where it's not a good idea to put / in LVM, but can you (or > someone else) define actually why it's not a good idea? It's not a good idea because: 1) It encourages poor management of file placement by vendors and users. 2) It complicates recovery of a failed system by requiring you to restore more than one disk to ensure consistent state. 3) It complicates cloning and replication of system images in that if you use a template VG structure, it is difficult to be able to import a VG for repair in another system if all the VG names are the same (ie, you can't easily fix it if all your VGs are called "system_vg", including the one in your recovery system). 4) It complicates getting a failed system back on the network so that you can fix whatever else happened. You don't see a lot of these problems in the Intel space because the network is less critical to Intel systems, and you can't really share access to resources between machines easily. As you migrate your Intel systems to virtual machines, the same problems start cropping up there too. ---------------------------------------------------------------------- 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
