Well I have done some work and now have something that is getting closer to what we would need here. This looks just like our non z systems. So our service areas would be happy-er
lvm> lvscan ACTIVE '/dev/VolGroup00/LogVol00' [1.00 GB] inherit ACTIVE '/dev/VolGroup00/opt' [2.00 GB] inherit ACTIVE '/dev/VolGroup00/tmp' [2.00 GB] inherit ACTIVE '/dev/VolGroup00/usr' [6.00 GB] inherit ACTIVE '/dev/VolGroup00/usr_local' [512.00 MB] inherit ACTIVE '/dev/VolGroup00/var' [3.00 GB] inherit ACTIVE '/dev/VolGroup00/LogVol01' [1.44 GB] inherit The mount point for each is /usr or /opt ... / is on LogVol00 * With /var now set to 3.00 GB does this allow /var to ONLY get as big as 3.00 GB and stop? OR would should each mount point be in it's own vol Group to achieve that? -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Thursday, March 22, 2007 12:01 PM To: [email protected] Subject: Re: can a max file size be set when using lvm The problem with a layout like this is the granularity. With the root being one large filesystem, and containing lots of other directories, you leave yourself open to possible failures that can be avoided if you use LVM and break up this filesystem. The /var and /tmp directories can consume space very quickly, leaving you with a root filesystem that is completely full without much notice. If these are broken off into their own filesystems, they're much more controlled, and can be more easily watched and problems diagnosed quicker. The /home filesystem has the same problem as the other two; A runaway task owned by some user can fill the filesystem quickly, leaving you... Surprised. Another problem comes if the guest needs to be re-imaged. Having /home in with the root filesystem means that you can't just scratch that filesystem and start over. You have to spend time moving data out, and then later back in. While you can allocate several smaller minidisks via zVM, you have to be able to maintain the structure. It's somewhat of a problem to expand a minidisk, while LVM allocations can be expanded and contracted very quickly, and additional minidisks can be added to the volume group to address future needs. Our current standard is to allocate two 3390 mod 9 equivalent minidisks to a new guest. The first becomes volume group vg_system, and is broken down into /tmp (500 mb), /var (2.5 gb), swap (1 gb) and the root directory (whatever's left). The second mod 9 becomes vg_local, and has /home (2 gb) and /opt (5.4 gb). We have most of our non-distribution software installed in the /opt path. If we need to move the users to another guest, we can move the second mod 9 to the other system, and they'd still have all their data and applications. If the users run out of room, it's fairly simple to add another volume to the volume group and expand the directory needing space. It's also fairly easy to create another logical volume in the group and add another path and filesystem when needed. We haven't really seen any crashes due to root being in LVM. Where we have had trouble, we'd have had the same problem with a flat filesystem as well. Logging in twice comes to mind... Note too that we set up our Intel-based Linux boxes in much the same way. In this way, we can walk up to any "box" and have some reasonable expectations. On logrotate: This tool does a great job... For what it works with. An example where if fails to fit is sar data and reports, which already have a timestamp in the name. logrotate doesn't handle files in that format, so you end up having to come up with another way to control them. The rmf collector is another one that has this problem, except in the /opt path. Printing and e-mail can fill /var if there is some problem with a task creating files in these spaces. /var can still fill up, despite your best efforts to control it. This layout has worked very well for us... Your mileage may vary. -- .~. Robert P. Nix Mayo Foundation /V\ RO-OC-1-13 200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ ----- "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/22/07 10:16 AM, "Michael MacIsaac" <[EMAIL PROTECTED]> wrote: >> If in the install I set say 10 2.3g disks into one lvm >> Setting the Mount point to / > > Others have described issues when using a logical volume for the root file > system. If LVM gets confused, which happens from time to time, then your > system doesn't boot. I would recommend keeping the root file system on a > conventional mindisk/DASD. > > -Maybe- you only want to use LVM when you have to. Suppose the base > system is three 3390-3s - one for /, one for /usr and one for /opt let's > say (or put / on a single 3390-9). If a minimal system is about 1GB (see > below), then your base system / is perhaps 17% used, /usr is 28% used and > /opt is pretty much empty. There's a fair amount of room for growth: > <snip> > > Then if you need to put a large chuck of data somewhere, you create an LVM > and mount it where it is needed. > > I feel the whole possible issue of "the root file system will fill up" is > overblown. logrotate does its job. Just my two cents - I sure others will > have different suggestions. > > "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
