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, Ry
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.
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
T
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
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
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 tri
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 strai
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-
>>
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
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,
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 m
>>> 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 kno
>>> 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
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
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.
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 M
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 th
> 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 a
> 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
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
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 PROT
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-
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
23 matches
Mail list logo
