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

Fri Oct 23 20:41:23 UTC 2009

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 at 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 at comedia.it
>  > <mailto:bluca at 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 at redhat.com <mailto:linux-lvm at 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 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20091023/322c64b2/attachment.htm>