Ryan McCain wrote:
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.
In the x86 world, we've been putting / in LVM for years and have never had a
problem. Is there something specific about z/VM that doesn't play well with /
in LVM?
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?
Because, unlike x86 boxes, you can't just drop in a CD and recover the
LVM. It's much easier to fix things when you can get the initial system
up without many headaches.
I look at it as I was taught a few years ago for LPI certification. It
talked about the bad old days when disks were small and you needed to
stretch the file systems across may of them. You would have a basic
local system with /, /root, /boot, /etc, and /sbin available locally and
could have the rest available through NFS or other shared disk interfaces.
I look on the z systems the same way; put at least those in a static
partition and the rest could go into LVM. Of course, you can extend any
part of the filesystem with mounts in LVM space later. That way I have
at least enough to figure out and fix the LVM if it hiccups.
Kim
----------------------------------------------------------------------
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
begin:vcard
fn:Kim Goldenberg
n:Goldenberg;Kim
org:State of New Jersey;Office of Information Technology (OIT)
adr:200 Riverview Plaza;;PO Box 212;Trenton;NJ;08625-0212;USA
email;internet:[EMAIL PROTECTED]
title:Systems Programmer I
tel;work:609-777-3722
tel;fax:609-777-3939
x-mozilla-html:FALSE
url:http://www.state.nj.us
version:2.1
end:vcard
