Re: Root filesystem
See lvreduce .. also vgreduce (but you can only remove unused physical volumes which ain't always easy). If you do a 'man lvreduce' it will caution you that you need to resize the filesystem before you resize the LV.. pay attention to that :-) Scott Rohling On Fri, Aug 15, 2008 at 11:24 AM, Ryan McCain <[EMAIL PROTECTED]>wrote: > We are mainly an EXT3 shop. I know z/VM can grow an LVMd EXT3 fs, just not > sure if it has the ability to shrink it. > > >>> On Fri, Aug 15, 2008 at 12:07 PM, in message > <[EMAIL PROTECTED]>, > "Fargusson.Alan" <[EMAIL PROTECTED]> wrote: > > It depends on the filesystem. Some can shrink and some can't. Also some > can > > shrink only if there are no used blocks in the area that is going to be > > removed. > > > > -Original Message- > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > > Ryan McCain > > Sent: Friday, August 15, 2008 9:43 AM > > To: LINUX-390@VM.MARIST.EDU > > Subject: Re: Root filesystem > > > > > > Is it possible to shrink a LVM fs, not just grow it? > > > On Fri, Aug 15, 2008 at 11:04 AM, in message > > <[EMAIL PROTECTED]>, Mark Post > > <[EMAIL PROTECTED]> wrote: > > On 8/15/2008 at 12:58 AM, in message < > [EMAIL PROTECTED]>, Mark > >> Perry <[EMAIL PROTECTED]> wrote: > >> -snip- > >>> Is there a way to trigger a script when a filesystem (FS) hits a > certain > >>> percentage full? (90%?) > >> > >> Of course. I have such a thing set up on my Slack/390 development > systems > >> so that I know when to temporarily suspend rsynching from my "upstream" > >> source at slackware.com. > >> > >>> If so, then one could develop a method to automatically issue the > >>> required lvresize and ext2online commands to keep the FS within a > >>> certain percentage range (70-90%?). Of course rules could be developed > >>> to make this more sophisticated: > >>> which FS are controlled, what % range per FS, limits of VG % free etc. > >> > >> You're certainly willing to do that to yourself. I would not want to do > it, > > > >> nor make that available to others. That sort of thing is very, very, > >> complicated, and I would want a human looking at that and making > decisions, > >> not software. > >> > >> > >> Mark Post > >> > >> -- > >> 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 > > > > > > > __ > > > > CONFIDENTIALITY NOTICE: This email from the State of California is for > the > > sole use of the intended recipient and may contain confidential and > > privileged information. Any unauthorized review or use, including > disclosure > > or distribution, is prohibited. If you are not the intended recipient, > > please contact the sender and destroy all copies of this email. > > > > -- > > 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
Re: Root filesystem
We are mainly an EXT3 shop. I know z/VM can grow an LVMd EXT3 fs, just not sure if it has the ability to shrink it. >>> On Fri, Aug 15, 2008 at 12:07 PM, in message <[EMAIL PROTECTED]>, "Fargusson.Alan" <[EMAIL PROTECTED]> wrote: > It depends on the filesystem. Some can shrink and some can't. Also some can > shrink only if there are no used blocks in the area that is going to be > removed. > > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Ryan McCain > Sent: Friday, August 15, 2008 9:43 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: Root filesystem > > > Is it possible to shrink a LVM fs, not just grow it? > On Fri, Aug 15, 2008 at 11:04 AM, in message > <[EMAIL PROTECTED]>, Mark Post > <[EMAIL PROTECTED]> wrote: > On 8/15/2008 at 12:58 AM, in message <[EMAIL PROTECTED]>, Mark >> Perry <[EMAIL PROTECTED]> wrote: >> -snip- >>> Is there a way to trigger a script when a filesystem (FS) hits a certain >>> percentage full? (90%?) >> >> Of course. I have such a thing set up on my Slack/390 development systems >> so that I know when to temporarily suspend rsynching from my "upstream" >> source at slackware.com. >> >>> If so, then one could develop a method to automatically issue the >>> required lvresize and ext2online commands to keep the FS within a >>> certain percentage range (70-90%?). Of course rules could be developed >>> to make this more sophisticated: >>> which FS are controlled, what % range per FS, limits of VG % free etc. >> >> You're certainly willing to do that to yourself. I would not want to do it, > >> nor make that available to others. That sort of thing is very, very, >> complicated, and I would want a human looking at that and making decisions, >> not software. >> >> >> Mark Post >> >> -- >> 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 > > > __ > > CONFIDENTIALITY NOTICE: This email from the State of California is for the > sole use of the intended recipient and may contain confidential and > privileged information. Any unauthorized review or use, including disclosure > or distribution, is prohibited. If you are not the intended recipient, > please contact the sender and destroy all copies of this email. > > -- > 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
Re: Root filesystem
It depends on the filesystem. Some can shrink and some can't. Also some can shrink only if there are no used blocks in the area that is going to be removed. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Friday, August 15, 2008 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Is it possible to shrink a LVM fs, not just grow it? >>> On Fri, Aug 15, 2008 at 11:04 AM, in message <[EMAIL PROTECTED]>, Mark Post <[EMAIL PROTECTED]> wrote: On 8/15/2008 at 12:58 AM, in message <[EMAIL PROTECTED]>, Mark > Perry <[EMAIL PROTECTED]> wrote: > -snip- >> Is there a way to trigger a script when a filesystem (FS) hits a certain >> percentage full? (90%?) > > Of course. I have such a thing set up on my Slack/390 development systems > so that I know when to temporarily suspend rsynching from my "upstream" > source at slackware.com. > >> If so, then one could develop a method to automatically issue the >> required lvresize and ext2online commands to keep the FS within a >> certain percentage range (70-90%?). Of course rules could be developed >> to make this more sophisticated: >> which FS are controlled, what % range per FS, limits of VG % free etc. > > You're certainly willing to do that to yourself. I would not want to do it, > nor make that available to others. That sort of thing is very, very, > complicated, and I would want a human looking at that and making decisions, > not software. > > > Mark Post > > -- > 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 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- 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
Re: Root filesystem
This seems odd to me. If I were the user getting charged by the amount of space I would not want it to grow without being told I was going to be charged more. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Friday, August 15, 2008 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem This would be an obvious use of Jack Wohr's pigiron tool (although bearing the cost of a JVM might be more mass than is really supportable). VM SMAPI provides functions to add minidisks to a guest, and the automation to access the disk, put it online and do the pvcreate, etc would be fairly straightforward once you have the ability to interact with the hypervisor management infrastructure. The filesystem monitor interface might be the only moderately complex part. Wrt to why, if you have a chargeback environment, preallocating space you're not using makes users whiny. Create on use makes that discussion less complex (they still whine, but it's clear what happened and why). -- 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 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- 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
Re: Root filesystem
I have problems with this kind of thing on z/OS Unix. Our /tmp filesystem on z/OS is nearly a full volume with usage around 2% because DB2 was configured to write a log file to /tmp, and someone ran a load test that cause DB2 to write 1.2G of log data. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Scott Rohling Sent: Friday, August 15, 2008 9:37 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem That was my first thought too... BUT - I can see how it could be useful to have free space in a VG and then assign it where it might be needed as it's needed within the VG. (Leave 1GB of the VG unassigned, and let the script assign it on an 'emergency' basis to the LV that is running low). More interesting is the notion of getting VM to assign the disk and then have it automatically added to the VG. (Think application data). If the method involves just have a bunch of VM minidisks already assigned to the guest, ready to be added - then I agree - why not just assign them now. Scott Rohling On Fri, Aug 15, 2008 at 10:20 AM, Fargusson.Alan <[EMAIL PROTECTED]>wrote: > If you have disk sitting around that you could add to the VG then why not > add them to the VG when you create it, and make the filesystems large enough > that they don't need to grow? > > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Scott Rohling > Sent: Friday, August 15, 2008 9:11 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: Root filesystem > > > If you're talking about a VG that has free space and a script smart enough > to add the free space and do the resize, etc -- then it sounds nifty and > not > too hard. > > If you're talking about getting VM to give you another minidisk, which you > then add to the VG and then add space to the LV -- that's a magnitude more > complicated (but certainly doable with things like REXECD on VM, vmcp to > link the disks, etc). > > But still - that would be nifty too :-) Interesting idea... > > Scott Rohling > > On Fri, Aug 15, 2008 at 10:04 AM, Mark Post <[EMAIL PROTECTED]> wrote: > > > >>> On 8/15/2008 at 12:58 AM, in message < > [EMAIL PROTECTED]>, > > Mark > > Perry <[EMAIL PROTECTED]> wrote: > > -snip- > > > Is there a way to trigger a script when a filesystem (FS) hits a > certain > > > percentage full? (90%?) > > > > Of course. I have such a thing set up on my Slack/390 development > systems > > so that I know when to temporarily suspend rsynching from my "upstream" > > source at slackware.com. > > > > > If so, then one could develop a method to automatically issue the > > > required lvresize and ext2online commands to keep the FS within a > > > certain percentage range (70-90%?). Of course rules could be developed > > > to make this more sophisticated: > > > which FS are controlled, what % range per FS, limits of VG % free etc. > > > > You're certainly willing to do that to yourself. I would not want to do > > it, nor make that available to others. That sort of thing is very, very, > > complicated, and I would want a human looking at that and making > decisions, > > not software. > > > > > > Mark Post > > > > -- > > 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 > > > __ > > CONFIDENTIALITY NOTICE: This email from the State of California is for the > sole use of the intended recipient and may contain confidential and > privileged information. Any unauthorized review or use, including > disclosure or distribution, is prohibited. If you are not the intended > recipient, please contact the sender and destroy all copies of this email. > > -- > 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
Re: Root filesystem
Is it possible to shrink a LVM fs, not just grow it? >>> On Fri, Aug 15, 2008 at 11:04 AM, in message <[EMAIL PROTECTED]>, Mark Post <[EMAIL PROTECTED]> wrote: On 8/15/2008 at 12:58 AM, in message <[EMAIL PROTECTED]>, Mark > Perry <[EMAIL PROTECTED]> wrote: > -snip- >> Is there a way to trigger a script when a filesystem (FS) hits a certain >> percentage full? (90%?) > > Of course. I have such a thing set up on my Slack/390 development systems > so that I know when to temporarily suspend rsynching from my "upstream" > source at slackware.com. > >> If so, then one could develop a method to automatically issue the >> required lvresize and ext2online commands to keep the FS within a >> certain percentage range (70-90%?). Of course rules could be developed >> to make this more sophisticated: >> which FS are controlled, what % range per FS, limits of VG % free etc. > > You're certainly willing to do that to yourself. I would not want to do it, > nor make that available to others. That sort of thing is very, very, > complicated, and I would want a human looking at that and making decisions, > not software. > > > Mark Post > > -- > 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
Re: Root filesystem
This would be an obvious use of Jack Wohr's pigiron tool (although bearing the cost of a JVM might be more mass than is really supportable). VM SMAPI provides functions to add minidisks to a guest, and the automation to access the disk, put it online and do the pvcreate, etc would be fairly straightforward once you have the ability to interact with the hypervisor management infrastructure. The filesystem monitor interface might be the only moderately complex part. Wrt to why, if you have a chargeback environment, preallocating space you're not using makes users whiny. Create on use makes that discussion less complex (they still whine, but it's clear what happened and why). -- 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
Re: Root filesystem
Thanks for the info. I'm going to discuss this further with management. >>> On Fri, Aug 15, 2008 at 11:01 AM, in message <[EMAIL PROTECTED]>, Mark Post <[EMAIL PROTECTED]> wrote: On 8/15/2008 at 7:29 AM, in message <[EMAIL PROTECTED]>, > Ryan McCain <[EMAIL PROTECTED]> wrote: > -snip- >> It has at least one advantage for us. We are given very limited space to >> allocate for each guest. This method allows for the rapid installation of >> either single application/patch or mass deployment/upgrade via ZLM without >> having to guesstimate ahead of time that /opt will be 1.1 gig, /tmp will be >> 500 meg, etc. Using my example, if we need to grow /opt to 1.5 gig, we > would >> then have to shuffle sizes of other filesystems around. Would you agree or > >> am I missing something? > > That's not an advantage, it's a workaround for bad management decisions. > Coming to Novell from a company where our z/VM systems were overly resource > constrained, I completely understand your situation. The best you can do is > "do what you have to do" and document for management the potential risks and > business impact of their decision to not provide the necessary hardware > resources to do things the "right" way (understanding there is debate about > what "right" is). Then, if Murphy strikes, and people are asking why you did > things that way, you have covered yourself and your team as much as you can. > > If I were put (back) in your position, I wouild try to do some research > ahead of time to figure out what set of standardized system templates I might > be creating, and adjust the file system layout I favor to support those. > Just about everyone I've spoken to has done just that, whether / is on an LV > or not, and gotten those templates approved by security, etc. You don't want > every system you create to be a "one off" situation. That won't be to your > advantage in any way. In general, you shouldn't be having to install lots of > new packages, just maintenance, for the life of a particular guest. If you > are, then something in your ogranizational or development processes are > broken. > > > Mark Post > > -- > 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
Re: Root filesystem
That was my first thought too... BUT - I can see how it could be useful to have free space in a VG and then assign it where it might be needed as it's needed within the VG. (Leave 1GB of the VG unassigned, and let the script assign it on an 'emergency' basis to the LV that is running low). More interesting is the notion of getting VM to assign the disk and then have it automatically added to the VG. (Think application data). If the method involves just have a bunch of VM minidisks already assigned to the guest, ready to be added - then I agree - why not just assign them now. Scott Rohling On Fri, Aug 15, 2008 at 10:20 AM, Fargusson.Alan <[EMAIL PROTECTED]>wrote: > If you have disk sitting around that you could add to the VG then why not > add them to the VG when you create it, and make the filesystems large enough > that they don't need to grow? > > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Scott Rohling > Sent: Friday, August 15, 2008 9:11 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: Root filesystem > > > If you're talking about a VG that has free space and a script smart enough > to add the free space and do the resize, etc -- then it sounds nifty and > not > too hard. > > If you're talking about getting VM to give you another minidisk, which you > then add to the VG and then add space to the LV -- that's a magnitude more > complicated (but certainly doable with things like REXECD on VM, vmcp to > link the disks, etc). > > But still - that would be nifty too :-) Interesting idea... > > Scott Rohling > > On Fri, Aug 15, 2008 at 10:04 AM, Mark Post <[EMAIL PROTECTED]> wrote: > > > >>> On 8/15/2008 at 12:58 AM, in message < > [EMAIL PROTECTED]>, > > Mark > > Perry <[EMAIL PROTECTED]> wrote: > > -snip- > > > Is there a way to trigger a script when a filesystem (FS) hits a > certain > > > percentage full? (90%?) > > > > Of course. I have such a thing set up on my Slack/390 development > systems > > so that I know when to temporarily suspend rsynching from my "upstream" > > source at slackware.com. > > > > > If so, then one could develop a method to automatically issue the > > > required lvresize and ext2online commands to keep the FS within a > > > certain percentage range (70-90%?). Of course rules could be developed > > > to make this more sophisticated: > > > which FS are controlled, what % range per FS, limits of VG % free etc. > > > > You're certainly willing to do that to yourself. I would not want to do > > it, nor make that available to others. That sort of thing is very, very, > > complicated, and I would want a human looking at that and making > decisions, > > not software. > > > > > > Mark Post > > > > -- > > 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 > > > __ > > CONFIDENTIALITY NOTICE: This email from the State of California is for the > sole use of the intended recipient and may contain confidential and > privileged information. Any unauthorized review or use, including > disclosure or distribution, is prohibited. If you are not the intended > recipient, please contact the sender and destroy all copies of this email. > > -- > 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
Re: Root filesystem
If you have disk sitting around that you could add to the VG then why not add them to the VG when you create it, and make the filesystems large enough that they don't need to grow? -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Scott Rohling Sent: Friday, August 15, 2008 9:11 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem If you're talking about a VG that has free space and a script smart enough to add the free space and do the resize, etc -- then it sounds nifty and not too hard. If you're talking about getting VM to give you another minidisk, which you then add to the VG and then add space to the LV -- that's a magnitude more complicated (but certainly doable with things like REXECD on VM, vmcp to link the disks, etc). But still - that would be nifty too :-) Interesting idea... Scott Rohling On Fri, Aug 15, 2008 at 10:04 AM, Mark Post <[EMAIL PROTECTED]> wrote: > >>> On 8/15/2008 at 12:58 AM, in message <[EMAIL PROTECTED]>, > Mark > Perry <[EMAIL PROTECTED]> wrote: > -snip- > > Is there a way to trigger a script when a filesystem (FS) hits a certain > > percentage full? (90%?) > > Of course. I have such a thing set up on my Slack/390 development systems > so that I know when to temporarily suspend rsynching from my "upstream" > source at slackware.com. > > > If so, then one could develop a method to automatically issue the > > required lvresize and ext2online commands to keep the FS within a > > certain percentage range (70-90%?). Of course rules could be developed > > to make this more sophisticated: > > which FS are controlled, what % range per FS, limits of VG % free etc. > > You're certainly willing to do that to yourself. I would not want to do > it, nor make that available to others. That sort of thing is very, very, > complicated, and I would want a human looking at that and making decisions, > not software. > > > Mark Post > > -- > 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 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- 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
Re: Root filesystem
If you're talking about a VG that has free space and a script smart enough to add the free space and do the resize, etc -- then it sounds nifty and not too hard. If you're talking about getting VM to give you another minidisk, which you then add to the VG and then add space to the LV -- that's a magnitude more complicated (but certainly doable with things like REXECD on VM, vmcp to link the disks, etc). But still - that would be nifty too :-) Interesting idea... Scott Rohling On Fri, Aug 15, 2008 at 10:04 AM, Mark Post <[EMAIL PROTECTED]> wrote: > >>> On 8/15/2008 at 12:58 AM, in message <[EMAIL PROTECTED]>, > Mark > Perry <[EMAIL PROTECTED]> wrote: > -snip- > > Is there a way to trigger a script when a filesystem (FS) hits a certain > > percentage full? (90%?) > > Of course. I have such a thing set up on my Slack/390 development systems > so that I know when to temporarily suspend rsynching from my "upstream" > source at slackware.com. > > > If so, then one could develop a method to automatically issue the > > required lvresize and ext2online commands to keep the FS within a > > certain percentage range (70-90%?). Of course rules could be developed > > to make this more sophisticated: > > which FS are controlled, what % range per FS, limits of VG % free etc. > > You're certainly willing to do that to yourself. I would not want to do > it, nor make that available to others. That sort of thing is very, very, > complicated, and I would want a human looking at that and making decisions, > not software. > > > Mark Post > > -- > 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
Re: Root filesystem
>>> On 8/15/2008 at 12:58 AM, in message <[EMAIL PROTECTED]>, Mark Perry <[EMAIL PROTECTED]> wrote: -snip- > Is there a way to trigger a script when a filesystem (FS) hits a certain > percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my "upstream" source at slackware.com. > If so, then one could develop a method to automatically issue the > required lvresize and ext2online commands to keep the FS within a > certain percentage range (70-90%?). Of course rules could be developed > to make this more sophisticated: > which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- 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
Re: Root filesystem
>>> On 8/15/2008 at 7:29 AM, in message <[EMAIL PROTECTED]>, Ryan McCain <[EMAIL PROTECTED]> wrote: -snip- > It has at least one advantage for us. We are given very limited space to > allocate for each guest. This method allows for the rapid installation of > either single application/patch or mass deployment/upgrade via ZLM without > having to guesstimate ahead of time that /opt will be 1.1 gig, /tmp will be > 500 meg, etc. Using my example, if we need to grow /opt to 1.5 gig, we would > then have to shuffle sizes of other filesystems around. Would you agree or > am I missing something? That's not an advantage, it's a workaround for bad management decisions. Coming to Novell from a company where our z/VM systems were overly resource constrained, I completely understand your situation. The best you can do is "do what you have to do" and document for management the potential risks and business impact of their decision to not provide the necessary hardware resources to do things the "right" way (understanding there is debate about what "right" is). Then, if Murphy strikes, and people are asking why you did things that way, you have covered yourself and your team as much as you can. If I were put (back) in your position, I wouild try to do some research ahead of time to figure out what set of standardized system templates I might be creating, and adjust the file system layout I favor to support those. Just about everyone I've spoken to has done just that, whether / is on an LV or not, and gotten those templates approved by security, etc. You don't want every system you create to be a "one off" situation. That won't be to your advantage in any way. In general, you shouldn't be having to install lots of new packages, just maintenance, for the life of a particular guest. If you are, then something in your ogranizational or development processes are broken. Mark Post -- 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
sane-dasd-update
Obviously the by-id/by-path debate has been of fairly major concern on this list over the last week or so. Clearly, also, no distributor is interested in fixing it for the currently-shipping distributions. So I wrote a little tool to run post-install, which does nothing but identify whether you have by-id disk paths in your fstab or zipl.conf. If you do, it rewrites them to be by-path disk paths. If you use the - d option, it just prints the changed files to the screen. Normal operation is to leave it in /etc/whatever-by-path. If you're feeling brave, you can run it with -r and actually *replace* the files (this will also invoke zipl if it needs to), and if you're feeling *suicidal* you can run it with -c and -r together, and clean up all the old files. Please don't do this, and if you do it, don't tell me about it. Anyway: the current tool only exists for SLES10/s390x; it should be easily adapted to any other distro's s390 or s390x release, and it makes no sense whatsoever for non-s390(x) distros. There's an RPM package, the Perl script itself, and the spec file used to generate the RPM package from the Perl script. Don't use this as a model for either how to write Perl or spec files. My Perl is dumb and ugly, and my spec files are created my randomly flailing at the keyboard until it works. However, the current package works for me. That said: NO WARRANTY EXPRESS OR IMPLIED. Even if it's Friday and you've had plenty of cough syrup, don't run this in replace mode without trying it a couple times and making sure you like the output you get, and don't run it with -c -r, period. And if you replace zipl.conf by hand, don't forget to actually *run* zipl before you reboot. http://download.sinenomine.net/sane-dasd-update Enjoy! Adam -- 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
Re: Root filesystem
This only works if you have the tool that will change the UUID. Around here we have to do everything manually. I have no idea how I would change the UUID during the cloning process. Even if I did it is one more thing to remember to do. We don't use Red Hat, do I guess I don't have to worry. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of John Summerfield Sent: Thursday, August 14, 2008 8:47 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem David Boyes wrote: > > 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). > fyi Red Hat is moving from labelling filesystems to using UUIDs. I imagine it would be prudent for those cloning systems to include part that generates new UUIDs. You should also consider adding a script to your cloning process to change the default "standard" volume and group names to names that are unique. This would alleviate the problem of importing a VG for repair. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- 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 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email.
Re: Root filesystem
We have something like this on z/OS Unix. It does not work as well as you might think. All it does is push the space problems out to the volume level. We end up having to un-mount the filesystem, move it to a new volume, and re-mount it. I would vote to not do this on Linux. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Mark Perry Sent: Friday, August 15, 2008 12:59 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Mark Post wrote: On 8/14/2008 at 8:26 AM, in message <[EMAIL PROTECTED]>, > Ryan McCain <[EMAIL PROTECTED]> 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. > > Laid out properly, / will never grow. > > # df -h > FilesystemSize Used Avail Use% Mounted on > /dev/dasda1 388M 168M 200M 46% / > /dev/mapper/vg01-home 97M 4.4M 88M 5% /home > /dev/mapper/vg01-opt 74M 21M 50M 30% /opt > /dev/mapper/vg01-srv 1.2G 1.1G 100M 92% /srv > /dev/mapper/vg01-tmp 291M 34M 242M 13% /tmp > /dev/mapper/vg01-usr 2.0G 901M 1.1G 45% /usr > /dev/mapper/vg01-var 2.0G 608M 1.3G 32% /var > > Of course the amount of space dedicated to each LV will vary according to > specific needs. The fundamental concept is the same, and will (hopefully) be > the default on SLES11 if things go as I hope. > > > Mark Post > Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. Hint to distros: If such a method were available during the installation process then we would not need to make guesstimates of the LV sizes, they could be set small and allowed to grow as packages were installed. If a good idea. then maybe add this to LVM2 so that the whole process was synchronized without the possibility of a FS becoming full (based on rules of course). mark -- 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 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email.
Re: Root filesystem
Or just make sure you have good backups. Good and tested backups were the original Knoppix. :) >>> On Thu, Aug 14, 2008 at 10:33 PM, in message <[EMAIL PROTECTED]>, John Summerfield <[EMAIL PROTECTED]> wrote: > Scott Rohling wrote: > >> I think there are pros and cons - enough on both sides that I wouldn't flat >> out tell someone "don't do it".. Recovery is less easy, yes, but certainly >> possible - you just have more than one DASD to consider. >> >> I think this is one of those topics that is endlessly debatable, so it's >> best just to list the pros and cons (and not just the cons) and leave it to >> the implementer to decide why they may or may not want to use LVM for root. > > >> DASD. Then - make your system unbootable (put an error in your /etc/fstab >> or zipl.conf or something) .. and then try and recover it with both an LVM >> and non-LVM root. These are the kinds of pros and cons you have to weigh >> yourself.. > > My Linux experience is principally on Intellish hardware. > > My favourite rescue disk is Knoppix, preferably the latest but in a > pinch, whatever is to hand. It does not understand RH's LVM setup. > > OTOH RH/Fedora rescue CDs[1] do understand LVM and can mount the system > needing rescue. How it would actually handle an incorrect fstab I don't > know, but I would fully expect it to get the the point where I could > apply a little vim (or sed or echo) and fix it. It's probably > complicated to use an alternative standard system to rescue an > LVM-rooted system (but maybe not if the alternative doesn't use LVM). I > have seen problems discussed where duplicate volume/group names arose, > in Fedora. > > [1] and presumably install media in rescue mode. > > In a mainframe environment I'd want to do as I did on OS/2, have a small > utility/rescue system on hand for just such emergencies. > > > > > -- > > Cheers > John > > -- spambait > [EMAIL PROTECTED] [EMAIL PROTECTED] > -- Advice > http://webfoot.com/advice/email.top.php > http://www.catb.org/~esr/faqs/smart-questions.html > http://support.microsoft.com/kb/555375 > > You cannot reply off-list:-) > > -- > 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
Re: Root filesystem
> It's far worse than that. Having / on an LV has _zero_ advantages, since > there is never a need to expand the root file system. Having / on an LV > introduces additional risk, and will elongate recovery time. That makes the > decision very easy. More risk, no benefit, no deal. Put / on an "plain > partition." It has at least one advantage for us. We are given very limited space to allocate for each guest. This method allows for the rapid installation of either single application/patch or mass deployment/upgrade via ZLM without having to guesstimate ahead of time that /opt will be 1.1 gig, /tmp will be 500 meg, etc. Using my example, if we need to grow /opt to 1.5 gig, we would then have to shuffle sizes of other filesystems around. Would you agree or am I missing something? -- 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
Re: Root filesystem
> Red Hat is moving from labelling filesystems to using UUIDs. Ugh. > I imagine it would be prudent for those cloning systems to include part > that generates new UUIDs. Or use a method of addressing storage that DOESN'T tie a logical reference to a specific physical device. > You should also consider adding a script to your cloning process to > change the default "standard" volume and group names to names that are > unique. This would alleviate the problem of importing a VG for repair. But it also defeats a major purpose of cloning -- to create a large number of *identical* systems. If I change the VG name on every system to keep it "safe", I have to document that and I lose a major advantage. -- 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
Re: Regina and/of THE (The Hessling Editor) install?
I use VI to edit most configs and such, just to keep my hands dirty. But for any REAL editing I always use THE. On Thu, Aug 14, 2008 at 2:05 PM, Scott Rohling <[EMAIL PROTECTED]>wrote: > Concerning the original post -- I've used Regina REXX on zLinux and > continue > to do so on both zSeries and my x86 servers at home. It initially came > with > the SUSE distro as an addon package when I used (SLES7, 8?) it. > > Using REXX (25 years experience is hard to toss out the window) helped me > automate on Linux immediately with little learning curve. For example - I > recall a nifty program that looked at all your DASD on zLinux and gave a > report on how it was being used (virtual address is dasdx, mounted as x, > part of LVM x, not used, etc). Being new to Linux this would have taken 10 > times longer than it did otherwise (though admittedly, I would have learned > a ton along the way). > > Now I'm familiar with bash, perl, python, php, et al - and tend to use them > for simple tasks. But I still run home to Mama Rexx when I'm doing > something less than simple. REXX is just too cool to abandon.. > > Anyway - not sure I did anything here but confirm REXX can and is used on > Linux on z. It seems to be missing from the current distros I've looked > at > for z, though :-( > > Cowlishaw hero worshiper and fan club member: Scott Rohling > > p.s. I've used THE - but after being forced to edit where THE isn't > available - I've tended to stick with vi/vim for an editor. Now that I > know > the keystroke contortions, it's not as bad as it once seemed. > > On Wed, Aug 13, 2008 at 9:09 AM, Mark Post <[EMAIL PROTECTED]> wrote: > > > >>> On 8/12/2008 at 12:32 PM, in message > > <[EMAIL PROTECTED]>, Mauro > Souza > > <[EMAIL PROTECTED]> wrote: > > > Hi Mark, > > > > > > *checkinstall make install* doesn't actually installs anything, only > > creates > > > the RPM package. > > > > The version of checkinstall that I've used does install into the "live" > > file system, and then creates a package from that. So, you might want to > > verify that it does (or does not) do that on a test system before doing > it > > on a more important system. > > > > > > Mark Post > > > > -- > > 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 > -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
Re: Regina and/of THE (The Hessling Editor) install?
Sure would be nice if you could convince the powers that Regina and THE belong on the "main" binary DVD. At least in the z world. On Thu, Aug 14, 2008 at 5:08 PM, Mark Post <[EMAIL PROTECTED]> wrote: > >>> On 8/14/2008 at 11:05 AM, in message > <[EMAIL PROTECTED]>, Scott > Rohling > <[EMAIL PROTECTED]> wrote: > -snip- > > Anyway - not sure I did anything here but confirm REXX can and is used on > > Linux on z. It seems to be missing from the current distros I've looked > at > > for z, though :-( > > This recently came up here at SHARE. Regina is included on the SDK for > SLES9 and SLES10, not the "main" binary or source DVDs. > > > Mark Post > > -- > 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 > -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
Re: Root filesystem
All IN this long diatribe about root file system no one has mentioned one of the true got ya's - that is the symbolic links of GRUB/LILO. 'Where ever you go - There you are!! ' Richard (Gaz) Gasiorowski Global Solutions & Technology Principal Lead Infrastructure Architect 845-773-9243 Work 845-392-7889 Cell [EMAIL PROTECTED] Computer Sciences Corporation Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042, USA Registered in Nevada, USA No: C-489-59 - This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - John Summerfield <[EMAIL PROTECTED]> Sent by: Linux on 390 Port 08/14/2008 11:54 PM Please respond to Linux on 390 Port To LINUX-390@VM.MARIST.EDU cc Subject Re: Root filesystem Ryan McCain wrote: > Do you have every directory under / defined as its own filesystem? /etc, /boot, /var, /opt, /lib, etc.. ? Read the FHS which can be found at pathname.com. I don't think anyone's managed to put /boot on anything but a bare partition, at least on Intellish hardware. The system boot code has to be able to be found and able to find the kernel & initial ramdisk. /lib must be in the root filesystem, as must some others: see the FHS for details. /usr can be ro and shared. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- 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
Re: Root filesystem
Mark Post wrote: On 8/14/2008 at 8:26 AM, in message <[EMAIL PROTECTED]>, > Ryan McCain <[EMAIL PROTECTED]> 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. > > Laid out properly, / will never grow. > > # df -h > FilesystemSize Used Avail Use% Mounted on > /dev/dasda1 388M 168M 200M 46% / > /dev/mapper/vg01-home 97M 4.4M 88M 5% /home > /dev/mapper/vg01-opt 74M 21M 50M 30% /opt > /dev/mapper/vg01-srv 1.2G 1.1G 100M 92% /srv > /dev/mapper/vg01-tmp 291M 34M 242M 13% /tmp > /dev/mapper/vg01-usr 2.0G 901M 1.1G 45% /usr > /dev/mapper/vg01-var 2.0G 608M 1.3G 32% /var > > Of course the amount of space dedicated to each LV will vary according to > specific needs. The fundamental concept is the same, and will (hopefully) be > the default on SLES11 if things go as I hope. > > > Mark Post > Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. Hint to distros: If such a method were available during the installation process then we would not need to make guesstimates of the LV sizes, they could be set small and allowed to grow as packages were installed. If a good idea. then maybe add this to LVM2 so that the whole process was synchronized without the possibility of a FS becoming full (based on rules of course). mark -- 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
