[linux-lvm] Total free space using added VGs and LVs

[linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

These questions stem from experiments using the LVM GUI on a CentOS V5.3
system. It seems that I need some expert help, and I would be grateful for a
definitive answer because this has been troubling to me.

1) I have been trying to add a 2nd drive (one partition) to my system, and
then to see the total free space via the file browser. But this doesn't work
if I create a new volume group and add the drive to that. Why is this so?

2) I also tried adding the drive to the existing volume group (VolGroup00)
and created a new logical volume group (LogVol02) for the drive. But again,
the file browser shows different amounts of free space at root (31GB) vs
after the mount point of the new drive (/mnt/X2nd40GB) (35 GB). Why does it
not show 66 GB free no matter what folder I look at?

3) Only when I add the drive to the the existing volume group and logical
volume (VolGroup00/LogVol00) does the file browser show the total free space
(66 GB) no matter where I look in the folders. I understand why this is. (No
need for a reply for this).

Regards,
Lou.

[-- Attachment #2: Type: text/html, Size: 1102 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Stuart D. Gathman]

On Mon, 19 Oct 2009, Lou Arnold wrote:

> 1) I have been trying to add a 2nd drive (one partition) to my system, and
> then to see the total free space via the file browser. But this doesn't work
> if I create a new volume group and add the drive to that. Why is this so?

File system free space is unrelated to LVM free space.  The free space of
each VG is independent.  (That is a main point of multiple volume groups.)

> 2) I also tried adding the drive to the existing volume group (VolGroup00)
> and created a new logical volume group (LogVol02) for the drive. But again,
> the file browser shows different amounts of free space at root (31GB) vs
> after the mount point of the new drive (/mnt/X2nd40GB) (35 GB). Why does it
> not show 66 GB free no matter what folder I look at?

If file browser means file system browser, it would not be expected to show
LVM free space.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] Total free space using added VGs and LVs

[Drew]

> 2) I also tried adding the drive to the existing volume group (VolGroup00)
> and created a new logical volume group (LogVol02) for the drive. But again,
> the file browser shows different amounts of free space at root (31GB) vs
> after the mount point of the new drive (/mnt/X2nd40GB) (35 GB). Why does it
> not show 66 GB free no matter what folder I look at?

Free space, from the filesystem perspective, is based on how big the
underlying partition is. In this case you've created two "partitions"
( "/" and "/mnt/X2nd40GB") and now the free space is being reported
based on which partition the folder you're looking at resides in.

As an example, if I create a "partitioning" scheme in LVM (VolGroup01)
that mounts logical volumes at the following directories:

/ - 8GB/3GB free [LogVolRoot]
/home - 20GB/15GB free [LogVolHome]
/var - 5GB/1GB free [LogVolVar]

If I'm sitting in /home/andrew/mystuff the filesystem (LogVolHome)
will report I have say 15GB free. If I then move over to /var/www and
do the same there, I may only get 1GB reported free. This is because
free space is calculated based on which Logical Volume/filesystem I'm
sitting in at the time.

-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie

Re: [linux-lvm] Total free space using added VGs and LVs

[Drew]

> But I thought that the purpose of LVM was to make a number of partitions
> look like one big one. So I can understand that with an added volume group,
> the filsesystems are separate, but for my (2) below, I expected all LVM-type
> partitions to seen as one large one.

The purpose of LVM is to make a bunch of physical drives look like one
big pool of storage space. A Volume Group is a container into which
you plug physical volumes (drives) so that the logical volumes can
allocate space from the pool (volume group) as needed.

> 1) Why would you want several logical volumes in one volume group?

The same reason(s) you would want to partition a regular hard drive.

Maybe you only want /home to have 20GB so your kids can't flood the
computer with downloaded music. Maybe you want /var/www to have
restricted permissions so your home web server is less vulnerable to
hackers. Maybe you're running a PVR application like MythTV and want a
high-performance filesystem like XFS for storing recorded shows.

All of these can be done with logical volumes, and are often easier under LVM.


> 2) Why would you want several volume groups at all?

You don't need multiple volume groups on a single machine. There are
certain uses though in which it is beneficial, usually in commercial
use.


-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie

Re: [linux-lvm] Total free space using added VGs and LVs

[Drew]

>> > 1) Why would you want several logical volumes in one volume group?
>>
>> The same reason(s) you would want to partition a regular hard drive.
>>
>> Maybe you only want /home to have 20GB so your kids can't flood the
>> computer with downloaded music. Maybe you want /var/www to have
>> restricted permissions so your home web server is less vulnerable to
>> hackers. Maybe you're running a PVR application like MythTV and want a
>> high-performance filesystem like XFS for storing recorded shows.
>>
>> All of these can be done with logical volumes, and are often easier under
>> LVM.
>
>
> But then if the above is true, then you may as well simply mount the
> partition as normal and add an entry into the fstab file. You get no
> advantage one way or the other - is that true?

LVM does this better then regular disk partitioning. The fact that it
creates a pool of space is it's power.

Two examples.

Let's say you don't have LVM and partitioned your disk with some
leftover space. What happens if you change your mind and want to
increase the size of a partition? Now you have to juggle the
partitions on the disk while you move that free space around to a
place where the partition can be extended. I've done it before and
it's messy. LVM? Just use the lvextend command with the right
parameters and you're done.

Next. Say you have two 80GB disks each partitioned with two partitions
60GB & 20GB. Now say you need to add an extra partition 30GB in size.
How? With regular disks, you pretty much can't. With LVM, you'd have
40GB free and can just create the 30GB logical volume without worrying
about which disk.

As a side note, can you cc: the LVM list when you reply? I don't think
they're getting your side of this conversation.


-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

Yes, OK, I see the advantage in your examples.

I've tried this (add a drive to VolGroup00/LogVol00) and it certainly works,
but it is much more difficult to undo than 1) creating a new volume group
and new volume, or 2) adding the drive to VolGroup00 and creating a new
volume. I read the documentation, but the file system fails whenever I
reboot. After all, LogVol00 is mounted at root, you can't unmount root
to shrink the volume. If you assume that the drive is empty and so you don't
have any data to migrate, how does one do it?


On 10/19/09, Drew <drew.kay@gmail.com> wrote:
>
> >> > 1) Why would you want several logical volumes in one volume group?
> >>
> >> The same reason(s) you would want to partition a regular hard drive.
> >>
> >> Maybe you only want /home to have 20GB so your kids can't flood the
> >> computer with downloaded music. Maybe you want /var/www to have
> >> restricted permissions so your home web server is less vulnerable to
> >> hackers. Maybe you're running a PVR application like MythTV and want a
> >> high-performance filesystem like XFS for storing recorded shows.
> >>
> >> All of these can be done with logical volumes, and are often easier
> under
> >> LVM.
> >
> >
> > But then if the above is true, then you may as well simply mount the
> > partition as normal and add an entry into the fstab file. You get no
> > advantage one way or the other - is that true?
>
> LVM does this better then regular disk partitioning. The fact that it
> creates a pool of space is it's power.
>
> Two examples.
>
> Let's say you don't have LVM and partitioned your disk with some
> leftover space. What happens if you change your mind and want to
> increase the size of a partition? Now you have to juggle the
> partitions on the disk while you move that free space around to a
> place where the partition can be extended. I've done it before and
> it's messy. LVM? Just use the lvextend command with the right
> parameters and you're done.
>
> Next. Say you have two 80GB disks each partitioned with two partitions
> 60GB & 20GB. Now say you need to add an extra partition 30GB in size.
> How? With regular disks, you pretty much can't. With LVM, you'd have
> 40GB free and can just create the 30GB logical volume without worrying
> about which disk.
>
> As a side note, can you cc: the LVM list when you reply? I don't think
> they're getting your side of this conversation.
>
>
> --
> Drew
>
> "Nothing in life is to be feared. It is only to be understood."
> --Marie Curie
>

[-- Attachment #2: Type: text/html, Size: 3039 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Drew]

> I've tried this (add a drive to VolGroup00/LogVol00) and it certainly works,
> but it is much more difficult to undo than 1) creating a new volume group
> and new volume, or 2) adding the drive to VolGroup00 and creating a new
> volume. I read the documentation, but the file system fails whenever I
> reboot. After all, LogVol00 is mounted at root, you can't unmount root
> to shrink the volume. If you assume that the drive is empty and so you don't
> have any data to migrate, how does one do it?

Welcome to the joys of planning your partitions and their filesystems. :-)

When you're working with the root partition or any other partition
needed by the system you can't make changes while the LV is in use.
But then again, you are in the same boat with regular partitions, the
tools just change.

When you say migrate, are you meaning migrating to a larger drive? Or
do you mean migrate portions of the filesystem to a new logical volume
with free space?



-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

Somehow this message didn't get to the list, so here it is this time

On Tue, Oct 20, 2009 at 10:44 AM, Lou Arnold <larnolda1@gmail.com> wrote:

>
>
>  On 10/19/09, Drew <drew.kay@gmail.com> wrote:
>
>> When you say migrate, are you meaning migrating to a larger drive? Or
>> do you mean migrate portions of the filesystem to a new logical volume
>> with free space?
>> --
>> Drew
>
>
> The documentation wasn't specific. I believe the intent was simply to
> migrate the data to another logical volume to temporarily allow the source
> volume to be reduced and/or removed. But let's assume that has happened or
> that doesn't need to happen. So now we need to unmount LogVol00, reduce it
> to its original nunber of extents and then remount it (either before or
> after remount we remove the physical drive.) I assume you can't try this or
> you'll screw up your computer, but I have a system that I screw up and
> easily restore from a OS image. So no need to be too cautious.
>
Lou.

[-- Attachment #2: Type: text/html, Size: 1583 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Drew]

> The documentation wasn't specific. I believe the intent was simply to
> migrate the data to another logical volume to temporarily allow the source
> volume to be reduced and/or removed. But let's assume that has happened or
> that doesn't need to happen. So now we need to unmount LogVol00, reduce it
> to its original nunber of extents and then remount it (either before or
> after remount we remove the physical drive.) I assume you can't try this or
> you'll screw up your computer, but I have a system that I screw up and
> easily restore from a OS image. So no need to be too cautious.

I've done this on several occasions.

If you want to play with various scenarios in LVM, I'd recommend
reading the LVM How-To @ http://tldp.org/HOWTO/LVM-HOWTO/ . Sections
11 & 13 cover the most common tasks you'll encounter in LVM. Play
around, don't be afraid to break things, and if you have questions
feel free to give the list a shout.


-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1.1: Type: text/plain, Size: 1664 bytes --]

I read the How-To. It doesn't talk about the specific case or being mounted
at root, so I had to experiment. It is likely that commands were in the
wrong order, but I don't know what the right order is.

I have attached the terminal session I used. In the end it did not work.
There was still 66 GB free, and when I rebooted, the file system failed. The
superblock was too big.

I obviously don't understand the difference between pvresize, lvreduce and
vgreduce, and how  resize2fs  is related to these commands.

Hope you can help,
Lou.


On 10/21/09, Drew <drew.kay@gmail.com> wrote:
>
> > The documentation wasn't specific. I believe the intent was simply to
> > migrate the data to another logical volume to temporarily allow the
> source
> > volume to be reduced and/or removed. But let's assume that has happened
> or
> > that doesn't need to happen. So now we need to unmount LogVol00, reduce
> it
> > to its original nunber of extents and then remount it (either before or
> > after remount we remove the physical drive.) I assume you can't try this
> or
> > you'll screw up your computer, but I have a system that I screw up and
> > easily restore from a OS image. So no need to be too cautious.
>
> I've done this on several occasions.
>
> If you want to play with various scenarios in LVM, I'd recommend
> reading the LVM How-To @ http://tldp.org/HOWTO/LVM-HOWTO/ . Sections
> 11 & 13 cover the most common tasks you'll encounter in LVM. Play
> around, don't be afraid to break things, and if you have questions
> feel free to give the list a shout.
>
>
> --
> Drew
>
> "Nothing in life is to be feared. It is only to be understood."
> --Marie Curie
>

[-- Attachment #1.2: Type: text/html, Size: 2185 bytes --]

[-- Attachment #2: UndoTrial1.txt --]
[-- Type: text/plain, Size: 7487 bytes --]

[root@shoe ~]# vgdisplay
  --- Volume group ---
  VG Name               VolGroup00
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  7
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               75.16 GB
  PE Size               32.00 MB
  Total PE              2405
  Alloc PE / Size       2405 / 75.16 GB
  Free  PE / Size       0 / 0   
  VG UUID               jvz6xK-OCTu-NUfb-5ssk-QHEI-KosC-PHiJff
   
[root@shoe ~]# pvdisplay /dev/hdd
  --- Physical volume ---
  PV Name               /dev/hdd
  VG Name               VolGroup00
  PV Size               38.02 GB / not usable 19.05 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              1216
  Free PE               0
  Allocated PE          1216
  PV UUID               ggSPj8-N36N-dtC1-U5sL-pw23-ubGj-AdF9H3
   
[root@shoe ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       72G  2.2G   67G   4% /
/dev/hda1              99M   18M   76M  19% /boot
tmpfs                 252M     0  252M   0% /dev/shm

[root@shoe ~]# pvdisplay -m
  --- Physical volume ---
  PV Name               /dev/hda2
  VG Name               VolGroup00
  PV Size               37.17 GB / not usable 12.24 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              1189
  Free PE               0
  Allocated PE          1189
  PV UUID               vEuKec-0sYh-6H3u-30Ld-Aq1S-UyWN-i6vwEr
   
  --- Physical Segments ---
  Physical extent 0 to 1156:
    Logical volume      /dev/VolGroup00/LogVol00
    Logical extents     0 to 1156
  Physical extent 1157 to 1188:
    Logical volume      /dev/VolGroup00/LogVol01
    Logical extents     0 to 31
   
  --- Physical volume ---
  PV Name               /dev/hdd
  VG Name               VolGroup00
  PV Size               38.02 GB / not usable 19.05 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              1216
  Free PE               0
  Allocated PE          1216
  PV UUID               ggSPj8-N36N-dtC1-U5sL-pw23-ubGj-AdF9H3
   
  --- Physical Segments ---
  Physical extent 0 to 1215:
    Logical volume      /dev/VolGroup00/LogVol00
    Logical extents     1157 to 2372
   
[root@shoe ~]# pvresize --setphysicalvolumesize 00G /dev/hdd
  Physical volume "/dev/hdd" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
[root@shoe ~]# pvdisplay -m
  --- Physical volume ---
  PV Name               /dev/hda2
  VG Name               VolGroup00
  PV Size               37.17 GB / not usable 12.24 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              1189
  Free PE               0
  Allocated PE          1189
  PV UUID               vEuKec-0sYh-6H3u-30Ld-Aq1S-UyWN-i6vwEr
   
  --- Physical Segments ---
  Physical extent 0 to 1156:
    Logical volume      /dev/VolGroup00/LogVol00
    Logical extents     0 to 1156
  Physical extent 1157 to 1188:
    Logical volume      /dev/VolGroup00/LogVol01
    Logical extents     0 to 31
   
  --- Physical volume ---
  PV Name               /dev/hdd
  VG Name               VolGroup00
  PV Size               38.02 GB / not usable 18.86 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              1216
  Free PE               0
  Allocated PE          1216
  PV UUID               ggSPj8-N36N-dtC1-U5sL-pw23-ubGj-AdF9H3
   
  --- Physical Segments ---
  Physical extent 0 to 1215:
    Logical volume      /dev/VolGroup00/LogVol00
    Logical extents     1157 to 2372
   
[root@shoe ~]# pvremove -ff /dev/hdd
Really WIPE LABELS from physical volume "/dev/hdd" of volume group "VolGroup00" [y/n]? y
  WARNING: Wiping physical volume label from /dev/hdd of volume group "VolGroup00"
  Can't open /dev/hdd exclusively - not removing. Mounted filesystem?

[root@shoe ~]# lvreduce -l -1216 /dev/mapper/VolGroup00-LogVol00
  WARNING: Reducing active and open logical volume to 36.16 GB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LogVol00? [y/n]: y
  Reducing logical volume LogVol00 to 36.16 GB
  Logical volume LogVol00 successfully resized

[root@shoe ~]# pvremove -ff /dev/hdd
Really WIPE LABELS from physical volume "/dev/hdd" of volume group "VolGroup00" [y/n]? y
  WARNING: Wiping physical volume label from /dev/hdd of volume group "VolGroup00"
  Labels on physical volume "/dev/hdd" successfully wiped

[root@shoe ~]# vgreduce --removemissing VolGroup00
  Couldn't find device with uuid 'ggSPj8-N36N-dtC1-U5sL-pw23-ubGj-AdF9H3'.
  Couldn't find device with uuid 'ggSPj8-N36N-dtC1-U5sL-pw23-ubGj-AdF9H3'.
  Wrote out consistent volume group VolGroup00
--Its not clear why these messages come out. The PV is not there according to the LVM GUI.

[root@shoe ~]# vgdisplay
  --- Volume group ---
  VG Name               VolGroup00
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  10
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               37.16 GB
  PE Size               32.00 MB
  Total PE              1189
  Alloc PE / Size       1189 / 37.16 GB
  Free  PE / Size       0 / 0   
  VG UUID               jvz6xK-OCTu-NUfb-5ssk-QHEI-KosC-PHiJff
   
[root@shoe ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/VolGroup00/LogVol00
  VG Name                VolGroup00
  LV UUID                Q1ygc0-I2zj-1hQU-gDAa-MdzK-tTaP-gLHzLt
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                36.16 GB
  Current LE             1157
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0
   
  --- Logical volume ---
  LV Name                /dev/VolGroup00/LogVol01
  VG Name                VolGroup00
  LV UUID                PUGBXZ-RHX2-gdIR-kQSG-q8ct-2N1y-P555uJ
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                1.00 GB
  Current LE             32
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1
   
[root@shoe ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/hda2
  VG Name               VolGroup00
  PV Size               37.17 GB / not usable 12.24 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              1189
  Free PE               0
  Allocated PE          1189
  PV UUID               vEuKec-0sYh-6H3u-30Ld-Aq1S-UyWN-i6vwEr

[root@shoe ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       72G  2.2G   67G   4% /
/dev/hda1              99M   18M   76M  19% /boot
tmpfs                 252M     0  252M   0% /dev/shm
--You can see that there is still something wrong here, because VolGroup00-LogVol00 is still marked as 67G Available and of course its not. How do we fix that.

Re: [linux-lvm] Total free space using added VGs and LVs

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 2896 bytes --]

Lou,

I'm new to this list and have not posted here before, so I am not sure
if this is the advice you'd eventually get, but it seems like you should
focus on the basics. You will need to understand the individual
components before a the more task-oriented parts of a how-to will be of
use. Following a step-by-step guide will get you a result, but if you
don't understand the steps the result probably won't be of any use to you.

The how-to has a good breakdown of the anatomy of LVM; that might be the
best place to start, focusing on the differences between Physical
Volumes, Volume Groups, Logical Volumes and where in that arrangement a
filesystem is placed.


Lou Arnold wrote:
> I read the How-To. It doesn't talk about the specific case or being
> mounted at root, so I had to experiment. It is likely that commands
> were in the wrong order, but I don't know what the right order is.
>  
> I have attached the terminal session I used. In the end it did not work.
> There was still 66 GB free, and when I rebooted, the file system failed.
> The superblock was too big.
>  
> I obviously don't understand the difference between pvresize, lvreduce
> and vgreduce, and how  resize2fs  is related to these commands.
>  
> Hope you can help,
> Lou.
> 
>  
> On 10/21/09, *Drew* <drew.kay@gmail.com <mailto:drew.kay@gmail.com>> wrote:
> 
>     > The documentation wasn't specific. I believe the intent was simply to
>     > migrate the data to another logical volume to temporarily allow
>     the source
>     > volume to be reduced and/or removed. But let's assume that has
>     happened or
>     > that doesn't need to happen. So now we need to unmount LogVol00,
>     reduce it
>     > to its original nunber of extents and then remount it (either
>     before or
>     > after remount we remove the physical drive.) I assume you can't
>     try this or
>     > you'll screw up your computer, but I have a system that I screw up and
>     > easily restore from a OS image. So no need to be too cautious.
> 
>     I've done this on several occasions.
> 
>     If you want to play with various scenarios in LVM, I'd recommend
>     reading the LVM How-To @ http://tldp.org/HOWTO/LVM-HOWTO/ . Sections
>     11 & 13 cover the most common tasks you'll encounter in LVM. Play
>     around, don't be afraid to break things, and if you have questions
>     feel free to give the list a shout.
> 
> 
>     --
>     Drew
> 
>     "Nothing in life is to be feared. It is only to be understood."
>     --Marie Curie
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


-- 
Ryan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 4575 bytes --]

No, I'm confortable that I know the distinctions between PVs, VGs, and LVs.
But the command resize2fs doesn't belong with the LVM and that's perhaps
where the trouble is, in part anyway.

The other part of the problem is with the HOW-TO. It has a habit of saying
"to do this, use xyz command", then say "but you may need to do this before
hand". Here is an example from the tldp.org LVM How-To:
11.6. Removing physical volumes from a volume group
Make sure that the physical volume isn't used by any logical volumes by
using then 'pvdisplay' command:
# pvdisplay /dev/hda1

If the physical volume is still used you will have to migrate the data to
another physical volume using pvmove. (But I have nothing to move and no
pladce to move anything to.)

Then use 'vgreduce' to remove the physical volume:
# vgreduce my_volume_group /dev/hda1
-- Result: The message says that the PV is busy.

No where does it say how to make it not busy.

I tried "13.5. Removing an Old Disk" but that tries to move physical
extents. But again, I have nothing to move, and no place to move anything.

And..the examples show how to remove a disk when the LV is not mounted at
root.

So now I have to figure out what to do to make the logical volume not busy
and yet still let the computer operate. That last trial wasn't successful,
and I really don't know where to start.
On 10/21/09, Ryan Anderson <ryan@worldspice.net> wrote:
>
> Lou,
>
> I'm new to this list and have not posted here before, so I am not sure
> if this is the advice you'd eventually get, but it seems like you should
> focus on the basics. You will need to understand the individual
> components before a the more task-oriented parts of a how-to will be of
> use. Following a step-by-step guide will get you a result, but if you
> don't understand the steps the result probably won't be of any use to you.
>
> The how-to has a good breakdown of the anatomy of LVM; that might be the
> best place to start, focusing on the differences between Physical
> Volumes, Volume Groups, Logical Volumes and where in that arrangement a
> filesystem is placed.
>
>
> Lou Arnold wrote:
> > I read the How-To. It doesn't talk about the specific case or being
> > mounted at root, so I had to experiment. It is likely that commands
> > were in the wrong order, but I don't know what the right order is.
> >
> > I have attached the terminal session I used. In the end it did not work.
> > There was still 66 GB free, and when I rebooted, the file system failed.
> > The superblock was too big.
> >
> > I obviously don't understand the difference between pvresize, lvreduce
> > and vgreduce, and how  resize2fs  is related to these commands.
> >
> > Hope you can help,
> > Lou.
> >
> >
> > On 10/21/09, *Drew* <drew.kay@gmail.com <mailto:drew.kay@gmail.com>>
> wrote:
> >
> >     > The documentation wasn't specific. I believe the intent was simply
> to
> >     > migrate the data to another logical volume to temporarily allow
> >     the source
> >     > volume to be reduced and/or removed. But let's assume that has
> >     happened or
> >     > that doesn't need to happen. So now we need to unmount LogVol00,
> >     reduce it
> >     > to its original nunber of extents and then remount it (either
> >     before or
> >     > after remount we remove the physical drive.) I assume you can't
> >     try this or
> >     > you'll screw up your computer, but I have a system that I screw up
> and
> >     > easily restore from a OS image. So no need to be too cautious.
> >
> >     I've done this on several occasions.
> >
> >     If you want to play with various scenarios in LVM, I'd recommend
> >     reading the LVM How-To @ http://tldp.org/HOWTO/LVM-HOWTO/ . Sections
> >     11 & 13 cover the most common tasks you'll encounter in LVM. Play
> >     around, don't be afraid to break things, and if you have questions
> >     feel free to give the list a shout.
> >
> >
> >     --
> >     Drew
> >
> >     "Nothing in life is to be feared. It is only to be understood."
> >     --Marie Curie
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>
> --
> Ryan
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>

[-- Attachment #2: Type: text/html, Size: 5875 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Stuart D. Gathman]

On Thu, 22 Oct 2009, Lou Arnold wrote:

> If the physical volume is still used you will have to migrate the data to
> another physical volume using pvmove. (But I have nothing to move and no
> pladce to move anything to.)

Apparently you *do* have stuff to move, hence why it is busy.  If you
have nowhere to move it to, then you can't remove the
physical volume.  (For that, you'll have to wait for quantum storage,
where storage space can be "borrowed" from the vacuum as long as it
is returned later.)

> Then use 'vgreduce' to remove the physical volume:
> # vgreduce my_volume_group /dev/hda1
> -- Result: The message says that the PV is busy.
> 
> No where does it say how to make it not busy.

It said you have to move all LE off the PV.  It is clear to me anyway.

> So now I have to figure out what to do to make the logical volume not busy
> and yet still let the computer operate. That last trial wasn't successful,
> and I really don't know where to start.

You can't make the logical volume not busy while it is mounted.  You can,
however, add another PV and use pvmove to move its extents to it.  That will
allow you to remove the original PV.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] Total free space using added VGs and LVs

[David]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

Is there anyway to recover a lost VolGroup if I have the UUID?


thanks,
David
On Wed, Oct 21, 2009 at 3:03 PM, Lou Arnold <larnolda1@gmail.com> wrote:

> I read the How-To. It doesn't talk about the specific case or being mounted
> at root, so I had to experiment. It is likely that commands were in the
> wrong order, but I don't know what the right order is.
>
> I have attached the terminal session I used. In the end it did not work.
> There was still 66 GB free, and when I rebooted, the file system failed. The
> superblock was too big.
>
> I obviously don't understand the difference between pvresize, lvreduce and
> vgreduce, and how  resize2fs  is related to these commands.
>
> Hope you can help,
> Lou.
>
>
> On 10/21/09, Drew <drew.kay@gmail.com> wrote:
>>
>> > The documentation wasn't specific. I believe the intent was simply to
>> > migrate the data to another logical volume to temporarily allow the
>> source
>> > volume to be reduced and/or removed. But let's assume that has happened
>> or
>> > that doesn't need to happen. So now we need to unmount LogVol00, reduce
>> it
>> > to its original nunber of extents and then remount it (either before or
>> > after remount we remove the physical drive.) I assume you can't try this
>> or
>> > you'll screw up your computer, but I have a system that I screw up and
>> > easily restore from a OS image. So no need to be too cautious.
>>
>> I've done this on several occasions.
>>
>> If you want to play with various scenarios in LVM, I'd recommend
>> reading the LVM How-To @ http://tldp.org/HOWTO/LVM-HOWTO/ . Sections
>> 11 & 13 cover the most common tasks you'll encounter in LVM. Play
>> around, don't be afraid to break things, and if you have questions
>> feel free to give the list a shout.
>>
>>
>> --
>> Drew
>>
>> "Nothing in life is to be feared. It is only to be understood."
>> --Marie Curie
>>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 3071 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Luca Berra]

On Wed, Oct 21, 2009 at 03:03:24PM -0400, Lou Arnold wrote:
>I read the How-To. It doesn't talk about the specific case or being mounted
I hate how-tos, they are a collection of particular cases and leave the
luser with a feeling of knowledge. which is not.

>at root, so I had to experiment. It is likely that commands were in the
>wrong order, but I don't know what the right order is.
>I have attached the terminal session I used. In the end it did not work.

the commands were not in the wrong order,
they were just the wrong commands, unless your aim was reinstalling.

>There was still 66 GB free, and when I rebooted, the file system failed. The
>superblock was too big.
>
>I obviously don't understand the difference between pvresize, lvreduce and
>vgreduce, and how  resize2fs  is related to these commands.

I think you need to go over the basics again
LVM is used to abstract storage management
it is done by creating layers
Physical Volumes: which represent disks (or partitions, or whatever
block device...)
Volume Group: which is a collection of disks
Logical Volume: which is a portion of a volume group

LVM allows to add/remove PVs to/from a VG. Add/remove/increase/shrink
LVs in a VG.
This is done by dividing each PV in Physical Extents (PE), and then
mapping those to Logical Extenst (LE) in a LV, so a LV is composed of
chunks of disk taken from one or more PV in a VG.

When using lvm you create filesystems over logical volumes instead of
creating them on disk (or partition....)

Lvm has no knowledge of what lays over it, a logical volume
is just a block device.

The above sentence means that if you use a logical volume to host a
filesystem and want to resize the lv, you have to deal with the
filesystem yourself.
i.e.
if you enlarge a LV, you have to tell the filesystem that the space
available has increased.
if you want to reduce an LV, you have to ensure _before_ doing it that
the space removed does not contain any data.
so if you want to reduce an LV containing a filesystem you _have_ to
tell the filesystem _before_ to let that space alone. if you fail to do
this you will loose all data that was on the portion of disk you
removed, and the filesystem will still think it can use that portion of
data, until it will actually try, then sudden realization will hit like
a brick. as you just discovered.

btw, let pvresize alone, it is used only in the particular case in which
you are able to resize the disk underlying a volume group, which is
impossible for a plain disk.

L.

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]

Luca, your comments make sense. After my last message I considered just what
you said, but I don't know how to prove it.

I know there is no data on the drive that I added, because I just added the
drive and never put data on it. I am sure "busy" means that it is
mounted. Because it is included in the default group/volume (VolGroup00 -
LogVol00) and because that LV is mounted at root ("/"), I cannot reduce the
filesystem with resize2fs; there is no way to unmount "/", that I know of,
anyway.   Unless of course someone knows how?
On Thu, Oct 22, 2009 at 11:52 PM, Luca Berra <bluca@comedia.it> wrote:

> On Wed, Oct 21, 2009 at 03:03:24PM -0400, Lou Arnold wrote:
>
>> I read the How-To. It doesn't talk about the specific case or being
>> mounted
>>
> I hate how-tos, they are a collection of particular cases and leave the
> luser with a feeling of knowledge. which is not.
>
>
> at root, so I had to experiment. It is likely that commands were in the
>> wrong order, but I don't know what the right order is.
>> I have attached the terminal session I used. In the end it did not work.
>>
>
> the commands were not in the wrong order,
> they were just the wrong commands, unless your aim was reinstalling.
>
>
> There was still 66 GB free, and when I rebooted, the file system failed.
>> The
>> superblock was too big.
>>
>> I obviously don't understand the difference between pvresize, lvreduce and
>> vgreduce, and how  resize2fs  is related to these commands.
>>
>
> I think you need to go over the basics again
> LVM is used to abstract storage management
> it is done by creating layers
> Physical Volumes: which represent disks (or partitions, or whatever
> block device...)
> Volume Group: which is a collection of disks
> Logical Volume: which is a portion of a volume group
>
> LVM allows to add/remove PVs to/from a VG. Add/remove/increase/shrink
> LVs in a VG.
> This is done by dividing each PV in Physical Extents (PE), and then
> mapping those to Logical Extenst (LE) in a LV, so a LV is composed of
> chunks of disk taken from one or more PV in a VG.
>
> When using lvm you create filesystems over logical volumes instead of
> creating them on disk (or partition....)
>
> Lvm has no knowledge of what lays over it, a logical volume
> is just a block device.
>
> The above sentence means that if you use a logical volume to host a
> filesystem and want to resize the lv, you have to deal with the
> filesystem yourself.
> i.e.
> if you enlarge a LV, you have to tell the filesystem that the space
> available has increased.
> if you want to reduce an LV, you have to ensure _before_ doing it that
> the space removed does not contain any data.
> so if you want to reduce an LV containing a filesystem you _have_ to
> tell the filesystem _before_ to let that space alone. if you fail to do
> this you will loose all data that was on the portion of disk you
> removed, and the filesystem will still think it can use that portion of
> data, until it will actually try, then sudden realization will hit like
> a brick. as you just discovered.
>
> btw, let pvresize alone, it is used only in the particular case in which
> you are able to resize the disk underlying a volume group, which is
> impossible for a plain disk.
>
> L.
>
>
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 4550 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 4563 bytes --]

Your best bet for resizing the root FS will be to use a LiveCD with LVM2
support. sysrescuecd works well, but likely your distribution install
disk can be booted with "linux rescue" or something similar.

Lou Arnold wrote:
> Luca, your comments make sense. After my last message I considered just
> what you said, but I don't know how to prove it.
> �
> I know there is no data on the drive that I added, because I just added
> the drive and never put data on it. I am sure "busy" means that it is
> mounted.�Because it is�included in the default group/volume (VolGroup00
> - LogVol00) and because that LV is mounted at root ("/"), I cannot
> reduce the filesystem with resize2fs; there is no way to unmount "/",
> that I know of, anyway.�� Unless of course someone knows how?
> On Thu, Oct 22, 2009 at 11:52 PM, Luca Berra <bluca@comedia.it
> <mailto:bluca@comedia.it>> wrote:
> 
>     On Wed, Oct 21, 2009 at 03:03:24PM -0400, Lou Arnold wrote:
> 
>         I read the How-To. It doesn't talk about the specific case or
>         being mounted
> 
>     I hate how-tos, they are a collection of particular cases and leave the
>     luser with a feeling of knowledge. which is not.
> 
> 
>         at root, so I had to experiment. It is likely that commands were
>         in the
>         wrong order, but I don't know what the right order is.
>         I have attached the terminal session I used. In the end it did
>         not work.
> 
> 
>     the commands were not in the wrong order,
>     they were just the wrong commands, unless your aim was reinstalling.
> 
> 
>         There was still 66 GB free, and when I rebooted, the file system
>         failed. The
>         superblock was too big.
> 
>         I obviously don't understand the difference between pvresize,
>         lvreduce and
>         vgreduce, and how �resize2fs �is related to these commands.
> 
> 
>     I think you need to go over the basics again
>     LVM is used to abstract storage management
>     it is done by creating layers
>     Physical Volumes: which represent disks (or partitions, or whatever
>     block device...)
>     Volume Group: which is a collection of disks
>     Logical Volume: which is a portion of a volume group
> 
>     LVM allows to add/remove PVs to/from a VG. Add/remove/increase/shrink
>     LVs in a VG.
>     This is done by dividing each PV in Physical Extents (PE), and then
>     mapping those to Logical Extenst (LE) in a LV, so a LV is composed of
>     chunks of disk taken from one or more PV in a VG.
> 
>     When using lvm you create filesystems over logical volumes instead of
>     creating them on disk (or partition....)
> 
>     Lvm has no knowledge of what lays over it, a logical volume
>     is just a block device.
> 
>     The above sentence means that if you use a logical volume to host a
>     filesystem and want to resize the lv, you have to deal with the
>     filesystem yourself.
>     i.e.
>     if you enlarge a LV, you have to tell the filesystem that the space
>     available has increased.
>     if you want to reduce an LV, you have to ensure _before_ doing it that
>     the space removed does not contain any data.
>     so if you want to reduce an LV containing a filesystem you _have_ to
>     tell the filesystem _before_ to let that space alone. if you fail to do
>     this you will loose all data that was on the portion of disk you
>     removed, and the filesystem will still think it can use that portion of
>     data, until it will actually try, then sudden realization will hit like
>     a brick. as you just discovered.
> 
>     btw, let pvresize alone, it is used only in the particular case in which
>     you are able to resize the disk underlying a volume group, which is
>     impossible for a plain disk.
> 
>     L.
> 
> 
> 
> 
> 
>     _______________________________________________
>     linux-lvm mailing list
>     linux-lvm@redhat.com <mailto:linux-lvm@redhat.com>
>     https://www.redhat.com/mailman/listinfo/linux-lvm
>     read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


-- 
Ryan Anderson
(901) 843 9300
Systems Engineer
WorldSpice Technologies


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 5824 bytes --]

Ryan, Thanks for your suggestion. I know it works, but I had hoped to have a
solution that didn't stop the whole system while I fixed it.

To Drew:
I think you were quite right when you spoke about planning the file system.
I've come to realize that my question is somewhat naive. One simply doesn't
do what I wanted to exactly because there is no easy way to dismantle it. It
would be better to partition off some part of the OS drive and add that to a
new volume group (or a new logical volume group) and mount that under
"/mnt", and then add whatever partitions on new drives to that logical
volume. That logical volume could be dismounted and worked on, whereas
whatever is under root cannot be worked on easily.
Regards,
Lou.

On Fri, Oct 23, 2009 at 1:12 PM, Ryan Anderson <ryan@worldspice.net> wrote:

> Your best bet for resizing the root FS will be to use a LiveCD with LVM2
> support. sysrescuecd works well, but likely your distribution install
> disk can be booted with "linux rescue" or something similar.
>
> Lou Arnold wrote:
> > Luca, your comments make sense. After my last message I considered just
> > what you said, but I don't know how to prove it.
> > �
> > I know there is no data on the drive that I added, because I just added
> > the drive and never put data on it. I am sure "busy" means that it is
> > mounted.�Because it is�included in the default group/volume (VolGroup00
> > - LogVol00) and because that LV is mounted at root ("/"), I cannot
> > reduce the filesystem with resize2fs; there is no way to unmount "/",
> > that I know of, anyway.�� Unless of course someone knows how?
> > On Thu, Oct 22, 2009 at 11:52 PM, Luca Berra <bluca@comedia.it
>  > <mailto:bluca@comedia.it>> wrote:
> >
> >     On Wed, Oct 21, 2009 at 03:03:24PM -0400, Lou Arnold wrote:
> >
> >         I read the How-To. It doesn't talk about the specific case or
> >         being mounted
> >
> >     I hate how-tos, they are a collection of particular cases and leave
> the
> >     luser with a feeling of knowledge. which is not.
> >
> >
> >         at root, so I had to experiment. It is likely that commands were
> >         in the
> >         wrong order, but I don't know what the right order is.
> >         I have attached the terminal session I used. In the end it did
> >         not work.
> >
> >
> >     the commands were not in the wrong order,
> >     they were just the wrong commands, unless your aim was reinstalling.
> >
> >
> >         There was still 66 GB free, and when I rebooted, the file system
> >         failed. The
> >         superblock was too big.
> >
> >         I obviously don't understand the difference between pvresize,
> >         lvreduce and
> >         vgreduce, and how �resize2fs �is related to these commands.
> >
> >
> >     I think you need to go over the basics again
> >     LVM is used to abstract storage management
> >     it is done by creating layers
> >     Physical Volumes: which represent disks (or partitions, or whatever
> >     block device...)
> >     Volume Group: which is a collection of disks
> >     Logical Volume: which is a portion of a volume group
> >
> >     LVM allows to add/remove PVs to/from a VG. Add/remove/increase/shrink
> >     LVs in a VG.
> >     This is done by dividing each PV in Physical Extents (PE), and then
> >     mapping those to Logical Extenst (LE) in a LV, so a LV is composed of
> >     chunks of disk taken from one or more PV in a VG.
> >
> >     When using lvm you create filesystems over logical volumes instead of
> >     creating them on disk (or partition....)
> >
> >     Lvm has no knowledge of what lays over it, a logical volume
> >     is just a block device.
> >
> >     The above sentence means that if you use a logical volume to host a
> >     filesystem and want to resize the lv, you have to deal with the
> >     filesystem yourself.
> >     i.e.
> >     if you enlarge a LV, you have to tell the filesystem that the space
> >     available has increased.
> >     if you want to reduce an LV, you have to ensure _before_ doing it
> that
> >     the space removed does not contain any data.
> >     so if you want to reduce an LV containing a filesystem you _have_ to
> >     tell the filesystem _before_ to let that space alone. if you fail to
> do
> >     this you will loose all data that was on the portion of disk you
> >     removed, and the filesystem will still think it can use that portion
> of
> >     data, until it will actually try, then sudden realization will hit
> like
> >     a brick. as you just discovered.
> >
> >     btw, let pvresize alone, it is used only in the particular case in
> which
> >     you are able to resize the disk underlying a volume group, which is
> >     impossible for a plain disk.
> >
> >     L.
> >
> >
> >
> >
> >
> >     _______________________________________________
> >     linux-lvm mailing list
> >     linux-lvm@redhat.com <mailto:linux-lvm@redhat.com>
> >     https://www.redhat.com/mailman/listinfo/linux-lvm
> >     read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> >
> >
> >
> > ------------------------------------------------------------------------
>  >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>
> --
> Ryan Anderson
> (901) 843 9300
> Systems Engineer
> WorldSpice Technologies
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 7551 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Brian McCullough]

On Fri, Oct 23, 2009 at 01:41:23PM -0700, Lou Arnold wrote:
> Ryan, Thanks for your suggestion. I know it works, but I had hoped to have a
> solution that didn't stop the whole system while I fixed it.
> 
> To Drew:
> I think you were quite right when you spoke about planning the file system.
> I've come to realize that my question is somewhat naive. One simply doesn't
> do what I wanted to exactly because there is no easy way to dismantle it. It
> would be better to partition off some part of the OS drive and add that to a
> new volume group (or a new logical volume group) and mount that under
> "/mnt", and then add whatever partitions on new drives to that logical
> volume. That logical volume could be dismounted and worked on, whereas
> whatever is under root cannot be worked on easily.


Lou,

I'm surprised that you haven't yet been told that one of the first rules of LVM is "don't use it for root!"  Actually, I don't really hold with that, but it is MUCH more important to plan what you are doing when you do have an LVM root partition.  As you have found, you can not manipulate an LVM partition while it is mounted. ( I know, there are ways for certain types of filesystems, but in general, the rule holds. )  That is especially true when the partition that you want to manipulate is root ( / ).

My general practice is to set up the following list of Logical Volumes ( the minimum which serves for most general purpose machines ): root, swap, home, usr, var.  I generally allocate somewhere around 1G for the root partition.  The others are sized appropriately for the environment.  That usually leaves me a lot of free space on modern drives for "data" space.

The recommendation that you should find a LiveCD at this point is probably one that you should respect.  Playing with mounted filesystems, particularly root, can rapidly lead you down a very nasty path.


Brian

Re: [linux-lvm] Total free space using added VGs and LVs

[Luca Berra]

On Fri, Oct 23, 2009 at 05:06:42PM -0700, Brian McCullough wrote:
>I'm surprised that you haven't yet been told that one of the first rules of LVM is "don't use it for root!"  Actually, I don't really hold with that, but it is MUCH more important to plan what you are doing when you do have an LVM root partition.  As you have found, you can not manipulate an LVM partition while it is mounted. ( I know, there are ways for certain types of filesystems, but in general, the rule holds. )  That is especially true when the partition that you want to manipulate is root ( / ).
There is no such rule.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

Haha, Yes, it would have been nice for someone to have told me about LVM and
root. It would have saved literally days of time. But my work is
experimental and never with production system. In any case, now I know
better.

As for the LiveCD suggestion, I did not intend to discount it. I had in fact
tried it several times, but with  some success. It probably just a matter of
finger problems for the failures. But I truly expected a graceful
dismantling process without the need of shutting down the system.

This was in fact a good experience. When you have to dig into things to
understand why something works or doesn't work, you are always luckier than
if things go perfectly right from the beginning.

Thanks to everyone for your help.
Lou.



On Fri, Oct 23, 2009 at 5:06 PM, Brian McCullough <bdmc@bdmcc-us.com> wrote:

> On Fri, Oct 23, 2009 at 01:41:23PM -0700, Lou Arnold wrote:
> > Ryan, Thanks for your suggestion. I know it works, but I had hoped to
> have a
> > solution that didn't stop the whole system while I fixed it.
> >
> > To Drew:
> > I think you were quite right when you spoke about planning the file
> system.
> > I've come to realize that my question is somewhat naive. One simply
> doesn't
> > do what I wanted to exactly because there is no easy way to dismantle it.
> It
> > would be better to partition off some part of the OS drive and add that
> to a
> > new volume group (or a new logical volume group) and mount that under
> > "/mnt", and then add whatever partitions on new drives to that logical
> > volume. That logical volume could be dismounted and worked on, whereas
> > whatever is under root cannot be worked on easily.
>
>
> Lou,
>
> I'm surprised that you haven't yet been told that one of the first rules of
> LVM is "don't use it for root!"  Actually, I don't really hold with that,
> but it is MUCH more important to plan what you are doing when you do have an
> LVM root partition.  As you have found, you can not manipulate an LVM
> partition while it is mounted. ( I know, there are ways for certain types of
> filesystems, but in general, the rule holds. )  That is especially true when
> the partition that you want to manipulate is root ( / ).
>
> My general practice is to set up the following list of Logical Volumes (
> the minimum which serves for most general purpose machines ): root, swap,
> home, usr, var.  I generally allocate somewhere around 1G for the root
> partition.  The others are sized appropriately for the environment.  That
> usually leaves me a lot of free space on modern drives for "data" space.
>
> The recommendation that you should find a LiveCD at this point is probably
> one that you should respect.  Playing with mounted filesystems, particularly
> root, can rapidly lead you down a very nasty path.
>
>
> Brian
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 3781 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[brem belguebli]

It's non sense arguing that LVM is not intended for root due to the
fact that you cannot shrink it  (growing online is operational and
works fine).

This is the only thing that is not allowed, though technically could
it be possible.



2009/10/24, Lou Arnold <larnolda1@gmail.com>:
> Haha, Yes, it would have been nice for someone to have told me about LVM and
> root. It would have saved literally days of time. But my work is
> experimental and never with production system. In any case, now I know
> better.
>
> As for the LiveCD suggestion, I did not intend to discount it. I had in fact
> tried it several times, but with  some success. It probably just a matter of
> finger problems for the failures. But I truly expected a graceful
> dismantling process without the need of shutting down the system.
>
> This was in fact a good experience. When you have to dig into things to
> understand why something works or doesn't work, you are always luckier than
> if things go perfectly right from the beginning.
>
> Thanks to everyone for your help.
> Lou.
>
>
>
> On Fri, Oct 23, 2009 at 5:06 PM, Brian McCullough <bdmc@bdmcc-us.com> wrote:
>
>> On Fri, Oct 23, 2009 at 01:41:23PM -0700, Lou Arnold wrote:
>> > Ryan, Thanks for your suggestion. I know it works, but I had hoped to
>> have a
>> > solution that didn't stop the whole system while I fixed it.
>> >
>> > To Drew:
>> > I think you were quite right when you spoke about planning the file
>> system.
>> > I've come to realize that my question is somewhat naive. One simply
>> doesn't
>> > do what I wanted to exactly because there is no easy way to dismantle
>> > it.
>> It
>> > would be better to partition off some part of the OS drive and add that
>> to a
>> > new volume group (or a new logical volume group) and mount that under
>> > "/mnt", and then add whatever partitions on new drives to that logical
>> > volume. That logical volume could be dismounted and worked on, whereas
>> > whatever is under root cannot be worked on easily.
>>
>>
>> Lou,
>>
>> I'm surprised that you haven't yet been told that one of the first rules
>> of
>> LVM is "don't use it for root!"  Actually, I don't really hold with that,
>> but it is MUCH more important to plan what you are doing when you do have
>> an
>> LVM root partition.  As you have found, you can not manipulate an LVM
>> partition while it is mounted. ( I know, there are ways for certain types
>> of
>> filesystems, but in general, the rule holds. )  That is especially true
>> when
>> the partition that you want to manipulate is root ( / ).
>>
>> My general practice is to set up the following list of Logical Volumes (
>> the minimum which serves for most general purpose machines ): root, swap,
>> home, usr, var.  I generally allocate somewhere around 1G for the root
>> partition.  The others are sized appropriately for the environment.  That
>> usually leaves me a lot of free space on modern drives for "data" space.
>>
>> The recommendation that you should find a LiveCD at this point is probably
>> one that you should respect.  Playing with mounted filesystems,
>> particularly
>> root, can rapidly lead you down a very nasty path.
>>
>>
>> Brian
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 4151 bytes --]

Hahaha. Brem, you and I think alike. If you can do it let me know. I don't
think people can think of a way to keep the system on-line and yet dismount
root so that LVM commands can work on it. If you can make it work, I'll buy
you a virtual beer.
Regards,
Lou.

On Sat, Oct 24, 2009 at 10:04 AM, brem belguebli
<brem.belguebli@gmail.com>wrote:

> It's non sense arguing that LVM is not intended for root due to the
> fact that you cannot shrink it  (growing online is operational and
> works fine).
>
> This is the only thing that is not allowed, though technically could
> it be possible.
>
>
>
> 2009/10/24, Lou Arnold <larnolda1@gmail.com>:
>  > Haha, Yes, it would have been nice for someone to have told me about
> LVM and
> > root. It would have saved literally days of time. But my work is
> > experimental and never with production system. In any case, now I know
> > better.
> >
> > As for the LiveCD suggestion, I did not intend to discount it. I had in
> fact
> > tried it several times, but with  some success. It probably just a matter
> of
> > finger problems for the failures. But I truly expected a graceful
> > dismantling process without the need of shutting down the system.
> >
> > This was in fact a good experience. When you have to dig into things to
> > understand why something works or doesn't work, you are always luckier
> than
> > if things go perfectly right from the beginning.
> >
> > Thanks to everyone for your help.
> > Lou.
> >
> >
> >
> > On Fri, Oct 23, 2009 at 5:06 PM, Brian McCullough <bdmc@bdmcc-us.com>
> wrote:
> >
> >> On Fri, Oct 23, 2009 at 01:41:23PM -0700, Lou Arnold wrote:
> >> > Ryan, Thanks for your suggestion. I know it works, but I had hoped to
> >> have a
> >> > solution that didn't stop the whole system while I fixed it.
> >> >
> >> > To Drew:
> >> > I think you were quite right when you spoke about planning the file
> >> system.
> >> > I've come to realize that my question is somewhat naive. One simply
> >> doesn't
> >> > do what I wanted to exactly because there is no easy way to dismantle
> >> > it.
> >> It
> >> > would be better to partition off some part of the OS drive and add
> that
> >> to a
> >> > new volume group (or a new logical volume group) and mount that under
> >> > "/mnt", and then add whatever partitions on new drives to that logical
> >> > volume. That logical volume could be dismounted and worked on, whereas
> >> > whatever is under root cannot be worked on easily.
> >>
> >>
> >> Lou,
> >>
> >> I'm surprised that you haven't yet been told that one of the first rules
> >> of
> >> LVM is "don't use it for root!"  Actually, I don't really hold with
> that,
> >> but it is MUCH more important to plan what you are doing when you do
> have
> >> an
> >> LVM root partition.  As you have found, you can not manipulate an LVM
> >> partition while it is mounted. ( I know, there are ways for certain
> types
> >> of
> >> filesystems, but in general, the rule holds. )  That is especially true
> >> when
> >> the partition that you want to manipulate is root ( / ).
> >>
> >> My general practice is to set up the following list of Logical Volumes (
> >> the minimum which serves for most general purpose machines ): root,
> swap,
> >> home, usr, var.  I generally allocate somewhere around 1G for the root
> >> partition.  The others are sized appropriately for the environment.
>  That
> >> usually leaves me a lot of free space on modern drives for "data" space.
> >>
> >> The recommendation that you should find a LiveCD at this point is
> probably
> >> one that you should respect.  Playing with mounted filesystems,
> >> particularly
> >> root, can rapidly lead you down a very nasty path.
> >>
> >>
> >> Brian
> >>
> >> _______________________________________________
> >> linux-lvm mailing list
> >> linux-lvm@redhat.com
> >> https://www.redhat.com/mailman/listinfo/linux-lvm
> >> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> >>
> >
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 5568 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[brem belguebli]

Hi Lou,

Who is talking about unmounting root ?

I'm just saying shrinking should be possible online as long as some
conditions are met (FS usage less than X %, reduced fragmentation ...)

Of course, this kind of procedure requiring a max of caution because
of the high risk of data loss, I'm not sure it'll get implemented in
the current tools.



2009/10/24, Lou Arnold <larnolda1@gmail.com>:
> Hahaha. Brem, you and I think alike. If you can do it let me know. I don't
> think people can think of a way to keep the system on-line and yet dismount
> root so that LVM commands can work on it. If you can make it work, I'll buy
> you a virtual beer.
> Regards,
> Lou.
>
> On Sat, Oct 24, 2009 at 10:04 AM, brem belguebli
> <brem.belguebli@gmail.com>wrote:
>
>> It's non sense arguing that LVM is not intended for root due to the
>> fact that you cannot shrink it  (growing online is operational and
>> works fine).
>>
>> This is the only thing that is not allowed, though technically could
>> it be possible.
>>
>>
>>
>> 2009/10/24, Lou Arnold <larnolda1@gmail.com>:
>>  > Haha, Yes, it would have been nice for someone to have told me about
>> LVM and
>> > root. It would have saved literally days of time. But my work is
>> > experimental and never with production system. In any case, now I know
>> > better.
>> >
>> > As for the LiveCD suggestion, I did not intend to discount it. I had in
>> fact
>> > tried it several times, but with  some success. It probably just a
>> > matter
>> of
>> > finger problems for the failures. But I truly expected a graceful
>> > dismantling process without the need of shutting down the system.
>> >
>> > This was in fact a good experience. When you have to dig into things to
>> > understand why something works or doesn't work, you are always luckier
>> than
>> > if things go perfectly right from the beginning.
>> >
>> > Thanks to everyone for your help.
>> > Lou.
>> >
>> >
>> >
>> > On Fri, Oct 23, 2009 at 5:06 PM, Brian McCullough <bdmc@bdmcc-us.com>
>> wrote:
>> >
>> >> On Fri, Oct 23, 2009 at 01:41:23PM -0700, Lou Arnold wrote:
>> >> > Ryan, Thanks for your suggestion. I know it works, but I had hoped to
>> >> have a
>> >> > solution that didn't stop the whole system while I fixed it.
>> >> >
>> >> > To Drew:
>> >> > I think you were quite right when you spoke about planning the file
>> >> system.
>> >> > I've come to realize that my question is somewhat naive. One simply
>> >> doesn't
>> >> > do what I wanted to exactly because there is no easy way to dismantle
>> >> > it.
>> >> It
>> >> > would be better to partition off some part of the OS drive and add
>> that
>> >> to a
>> >> > new volume group (or a new logical volume group) and mount that under
>> >> > "/mnt", and then add whatever partitions on new drives to that
>> >> > logical
>> >> > volume. That logical volume could be dismounted and worked on,
>> >> > whereas
>> >> > whatever is under root cannot be worked on easily.
>> >>
>> >>
>> >> Lou,
>> >>
>> >> I'm surprised that you haven't yet been told that one of the first
>> >> rules
>> >> of
>> >> LVM is "don't use it for root!"  Actually, I don't really hold with
>> that,
>> >> but it is MUCH more important to plan what you are doing when you do
>> have
>> >> an
>> >> LVM root partition.  As you have found, you can not manipulate an LVM
>> >> partition while it is mounted. ( I know, there are ways for certain
>> types
>> >> of
>> >> filesystems, but in general, the rule holds. )  That is especially true
>> >> when
>> >> the partition that you want to manipulate is root ( / ).
>> >>
>> >> My general practice is to set up the following list of Logical Volumes
>> >> (
>> >> the minimum which serves for most general purpose machines ): root,
>> swap,
>> >> home, usr, var.  I generally allocate somewhere around 1G for the root
>> >> partition.  The others are sized appropriately for the environment.
>>  That
>> >> usually leaves me a lot of free space on modern drives for "data"
>> >> space.
>> >>
>> >> The recommendation that you should find a LiveCD at this point is
>> probably
>> >> one that you should respect.  Playing with mounted filesystems,
>> >> particularly
>> >> root, can rapidly lead you down a very nasty path.
>> >>
>> >>
>> >> Brian
>> >>
>> >> _______________________________________________
>> >> linux-lvm mailing list
>> >> linux-lvm@redhat.com
>> >> https://www.redhat.com/mailman/listinfo/linux-lvm
>> >> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>> >>
>> >
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 5481 bytes --]

Brem,
I agree. I thought it should be possible. Perhaps someone else can try it
and let us know in a future blog. I just don't have enough experience to
take it farther.

Regards,
Lou.

On Sat, Oct 24, 2009 at 1:54 PM, brem belguebli <brem.belguebli@gmail.com>wrote:

> Hi Lou,
>
> Who is talking about unmounting root ?
>
> I'm just saying shrinking should be possible online as long as some
> conditions are met (FS usage less than X %, reduced fragmentation ...)
>
> Of course, this kind of procedure requiring a max of caution because
> of the high risk of data loss, I'm not sure it'll get implemented in
> the current tools.
>
>
>
> 2009/10/24, Lou Arnold <larnolda1@gmail.com>:
> > Hahaha. Brem, you and I think alike. If you can do it let me know. I
> don't
> > think people can think of a way to keep the system on-line and yet
> dismount
> > root so that LVM commands can work on it. If you can make it work, I'll
> buy
> > you a virtual beer.
> > Regards,
> > Lou.
> >
> > On Sat, Oct 24, 2009 at 10:04 AM, brem belguebli
> > <brem.belguebli@gmail.com>wrote:
> >
> >> It's non sense arguing that LVM is not intended for root due to the
> >> fact that you cannot shrink it  (growing online is operational and
> >> works fine).
> >>
> >> This is the only thing that is not allowed, though technically could
> >> it be possible.
> >>
> >>
> >>
> >> 2009/10/24, Lou Arnold <larnolda1@gmail.com>:
> >>  > Haha, Yes, it would have been nice for someone to have told me about
> >> LVM and
> >> > root. It would have saved literally days of time. But my work is
> >> > experimental and never with production system. In any case, now I know
> >> > better.
> >> >
> >> > As for the LiveCD suggestion, I did not intend to discount it. I had
> in
> >> fact
> >> > tried it several times, but with  some success. It probably just a
> >> > matter
> >> of
> >> > finger problems for the failures. But I truly expected a graceful
> >> > dismantling process without the need of shutting down the system.
> >> >
> >> > This was in fact a good experience. When you have to dig into things
> to
> >> > understand why something works or doesn't work, you are always luckier
> >> than
> >> > if things go perfectly right from the beginning.
> >> >
> >> > Thanks to everyone for your help.
> >> > Lou.
> >> >
> >> >
> >> >
> >> > On Fri, Oct 23, 2009 at 5:06 PM, Brian McCullough <bdmc@bdmcc-us.com>
> >> wrote:
> >> >
> >> >> On Fri, Oct 23, 2009 at 01:41:23PM -0700, Lou Arnold wrote:
> >> >> > Ryan, Thanks for your suggestion. I know it works, but I had hoped
> to
> >> >> have a
> >> >> > solution that didn't stop the whole system while I fixed it.
> >> >> >
> >> >> > To Drew:
> >> >> > I think you were quite right when you spoke about planning the file
> >> >> system.
> >> >> > I've come to realize that my question is somewhat naive. One simply
> >> >> doesn't
> >> >> > do what I wanted to exactly because there is no easy way to
> dismantle
> >> >> > it.
> >> >> It
> >> >> > would be better to partition off some part of the OS drive and add
> >> that
> >> >> to a
> >> >> > new volume group (or a new logical volume group) and mount that
> under
> >> >> > "/mnt", and then add whatever partitions on new drives to that
> >> >> > logical
> >> >> > volume. That logical volume could be dismounted and worked on,
> >> >> > whereas
> >> >> > whatever is under root cannot be worked on easily.
> >> >>
> >> >>
> >> >> Lou,
> >> >>
> >> >> I'm surprised that you haven't yet been told that one of the first
> >> >> rules
> >> >> of
> >> >> LVM is "don't use it for root!"  Actually, I don't really hold with
> >> that,
> >> >> but it is MUCH more important to plan what you are doing when you do
> >> have
> >> >> an
> >> >> LVM root partition.  As you have found, you can not manipulate an LVM
> >> >> partition while it is mounted. ( I know, there are ways for certain
> >> types
> >> >> of
> >> >> filesystems, but in general, the rule holds. )  That is especially
> true
> >> >> when
> >> >> the partition that you want to manipulate is root ( / ).
> >> >>
> >> >> My general practice is to set up the following list of Logical
> Volumes
> >> >> (
> >> >> the minimum which serves for most general purpose machines ): root,
> >> swap,
> >> >> home, usr, var.  I generally allocate somewhere around 1G for the
> root
> >> >> partition.  The others are sized appropriately for the environment.
> >>  That
> >> >> usually leaves me a lot of free space on modern drives for "data"
> >> >> space.
> >> >>
> >> >> The recommendation that you should find a LiveCD at this point is
> >> probably
> >> >> one that you should respect.  Playing with mounted filesystems,
> >> >> particularly
> >> >> root, can rapidly lead you down a very nasty path.
> >> >>
> >> >>
> >> >> Brian
> >> >>
> >> >> _______________________________________________
> >> >> linux-lvm mailing list
> >> >> linux-lvm@redhat.com
> >> >> https://www.redhat.com/mailman/listinfo/linux-lvm
> >> >> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> >> >>
> >> >
> >>
> >> _______________________________________________
> >> linux-lvm mailing list
> >> linux-lvm@redhat.com
> >> https://www.redhat.com/mailman/listinfo/linux-lvm
> >> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> >>
> >
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 8048 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Stuart D. Gathman]

On Sat, 24 Oct 2009, brem belguebli wrote:

> >> It's non sense arguing that LVM is not intended for root due to the
> >> fact that you cannot shrink it  (growing online is operational and
> >> works fine).
> >>
> >> This is the only thing that is not allowed, though technically could
> >> it be possible.

On some installs, I take the AIX approach an allocate a smallish / filesystem,
with others mounted.  If you can go to single user mode, you can unmount the
other filesystems (e.g. /usr) for shrinkage.  This doesn't, of course, meet the
goal of shrinking while in actual operation.

You can get closer by running production in a virtual machine (I like
xen).  Then you can shutdown, resize, and boot a VM without shutting
down the host.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] Total free space using added VGs and LVs

[Luca Berra]

On Sat, Oct 24, 2009 at 07:04:49PM +0200, brem belguebli wrote:
>It's non sense arguing that LVM is not intended for root due to the
>fact that you cannot shrink it  (growing online is operational and
>works fine).
>
>This is the only thing that is not allowed, though technically could
>it be possible.
>
Online shrinking is more difficult to achieve than online growing, and
is much less frequently needed, it usually happens due to bad planning.
I know some filesystem on different oses (namely vxfs) and btrfs on linux
allow online shrinking, ext3/4 and xfs don't.

The argument i find very difficult to grasp is what's so critical about
root filesystem versus other filesystems
If your server is (i.e.) a database server you will feel the filesystem
holding the database data is as critical as the root filesystem, if you
need to unmount that you might as well reboot. And the probability of
having to touch the data filesystem is much higher than that of having
to touch root.

Also the argument that the server is in a colo miles away is nonsense,
if it is a critical system it should have some means of oob management,
most server vendors offer those as standard components.

L.


-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: [linux-lvm] Total free space using added VGs and LVs

[Drew]

> Online shrinking is more difficult to achieve than online growing, and
> is much less frequently needed, it usually happens due to bad planning.
> I know some filesystem on different oses (namely vxfs) and btrfs on linux
> allow online shrinking, ext3/4 and xfs don't.

Ext3 does support shrinking. I've been doing it as far back as 2005.


-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie

Re: [linux-lvm] Total free space using added VGs and LVs

[Stuart D. Gathman]

On Sun, 25 Oct 2009, Drew wrote:

> > Online shrinking is more difficult to achieve than online growing, and
> > is much less frequently needed, it usually happens due to bad planning.
> > I know some filesystem on different oses (namely vxfs) and btrfs on linux
> > allow online shrinking, ext3/4 and xfs don't.
> 
> Ext3 does support shrinking. I've been doing it as far back as 2005.

But not while mounted.  (AFAIK)

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] Total free space using added VGs and LVs

[Stuart D. Gathman]

On Sun, 25 Oct 2009, Stuart D. Gathman wrote:

> > Ext3 does support shrinking. I've been doing it as far back as 2005.
> 
> But not while mounted.  (AFAIK)

Poor man's approach:

1) single user mode
2) remount root readonly
3) run resize2fs - force it to proceed despite (warranted) dire warnings
4) switch root (remount won't be good enough since it changed "underfoot")

Of course, while technically "mounted", it might as well be unmounted
since you can't keep running applications.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] Total free space using added VGs and LVs

[Lou Arnold]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

Hat do you mean by:"4) switch root (remount won't be good enough since it
changed "underfoot")"
Can you please explain?


On Sun, Oct 25, 2009 at 12:17 PM, Stuart D. Gathman <stuart@bmsi.com> wrote:

> On Sun, 25 Oct 2009, Stuart D. Gathman wrote:
>
> > > Ext3 does support shrinking. I've been doing it as far back as 2005.
> >
> > But not while mounted.  (AFAIK)
>
> Poor man's approach:
>
> 1) single user mode
> 2) remount root readonly
> 3) run resize2fs - force it to proceed despite (warranted) dire warnings
> 4) switch root (remount won't be good enough since it changed "underfoot")
>
> Of course, while technically "mounted", it might as well be unmounted
> since you can't keep running applications.
>
> --
>              Stuart D. Gathman <stuart@bmsi.com>
>    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
> "Confutatis maledictis, flammis acribus addictis" - background song for
> a Microsoft sponsored "Where do you want to go from here?" commercial.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 1909 bytes --]

Re: [linux-lvm] Total free space using added VGs and LVs

[Stuart D. Gathman]

On Mon, 26 Oct 2009, Lou Arnold wrote:

> Hat do you mean by:"4) switch root (remount won't be good enough since it
> changed "underfoot")"
> Can you please explain?

You can't change a filesystem by directly writing the block device while
it is mounted, without hopelessly confusing the filesystem driver. 
(Exceptions would be filesystems designed to be updated by multiple
computers - but these have their own limitations.)

Switchroot actually closes all files, umounts root fs, and mounts it again.
It is normally used at the end of initrd to switch from the ramdisk root
to the real root filesystem.  Not much better than a reboot actually,
but technically not a reboot :-)

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.