linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
* [linux-lvm] "Condensing" Physical Volumes
@ 2010-12-04 18:06 David Baron
  2010-12-04 19:28 ` Ray Morris
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: David Baron @ 2010-12-04 18:06 UTC (permalink / raw)
  To: linux-lvm

I need more extents to move stuff off older, possibly failing IDE disks to my 
new SATA terrabyter. However, not enough extents are available. The disk is 
very sparsely populated.

Is there any way to "condense" physical volumes to recover/expose empty 
extents in order to make use of them?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-lvm] "Condensing" Physical Volumes
  2010-12-04 18:06 [linux-lvm] "Condensing" Physical Volumes David Baron
@ 2010-12-04 19:28 ` Ray Morris
  2010-12-04 19:38 ` Lars Ellenberg
  2010-12-04 19:40 ` Ray Morris
  2 siblings, 0 replies; 5+ messages in thread
From: Ray Morris @ 2010-12-04 19:28 UTC (permalink / raw)
  To: LVM general discussion and development

> However, not enough extents are available.
> 
> Is there any way to "condense" physical volumes to
> recover/expose empty extents in order to make use of them?

   You say there are few free extents, then you say there
are many "empty" extents.  It sounds like we need to get very
clear on exactly what is free, what is empty, what is
sparse, etc.

> The disk is very sparsely populated.

The disk is probably the PV, which is full of extents.
Therefore, the disk is fully populated (with extents).
Perhaps the disk is a component of a RAID array and
the array is the PV.  Either way, the disk is probably
full of something (RAID blocks, LVM extents, whatever).


    Is your situation actually the following?:

The volume group is nearly full, meaning that most all
of the extents are used by logical volumes.

On those logical volumes you have file systems.

Those file systems have free space.

If the above three conditions hold, you'd need to:

reduce the size of the file systems, perhaps using ex2resize.

Once each file system is reduced, you would then be able to reduce
the logical volume which contains that filesystem.

That will mean there are free extents in the volume group, so you can
then use pvmove to move the extents off of the chosen physical
volumes.
--
Ray Morris
support@bettercgi.com

Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/

Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/

Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php


On 12/04/2010 12:06:46 PM, David Baron wrote:
> I need more extents to move stuff off older, possibly failing IDE  
> disks to my
> new SATA terrabyter. However, not enough extents are available. The  
> disk is
> very sparsely populated.
> 
> Is there any way to "condense" physical volumes to recover/expose  
> empty
> extents in order to make use of them?
> 
> _______________________________________________
> 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/
> 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-lvm] "Condensing" Physical Volumes
  2010-12-04 18:06 [linux-lvm] "Condensing" Physical Volumes David Baron
  2010-12-04 19:28 ` Ray Morris
@ 2010-12-04 19:38 ` Lars Ellenberg
  2010-12-04 19:40 ` Ray Morris
  2 siblings, 0 replies; 5+ messages in thread
From: Lars Ellenberg @ 2010-12-04 19:38 UTC (permalink / raw)
  To: linux-lvm

On Sat, Dec 04, 2010 at 08:06:46PM +0200, David Baron wrote:
> I need more extents to move stuff off older, possibly failing IDE disks to my 
> new SATA terrabyter. However, not enough extents are available. The disk is 
> very sparsely populated.
> 
> Is there any way to "condense" physical volumes to recover/expose empty 
> extents in order to make use of them?

Does pvmove --alloc anywhere help?

Alternatively, you can specify exactly which extents go where,
like in "pvmove --test -n lvname.to.move /dev/pvold:20-27 /dev/pvnew:732-739".
obviously, remove --test, if it seems to do what you meant.

To see which what is where, and which extent ranges are free,
I tend to use variants of
pvs -o vg_name,lv_name,pv_name,pvseg_start,pvseg_size,seg_pe_ranges -Opv_name,pvseg_start
Note that pe_ranges are inclusive, (end of the range is: pvseg_start  + pvseg_size -1).

hth,

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD� and LINBIT� are registered trademarks of LINBIT, Austria.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-lvm] "Condensing" Physical Volumes
  2010-12-04 18:06 [linux-lvm] "Condensing" Physical Volumes David Baron
  2010-12-04 19:28 ` Ray Morris
  2010-12-04 19:38 ` Lars Ellenberg
@ 2010-12-04 19:40 ` Ray Morris
  2 siblings, 0 replies; 5+ messages in thread
From: Ray Morris @ 2010-12-04 19:40 UTC (permalink / raw)
  To: LVM general discussion and development

   A followup for the case where it's the filesystems that
have free space.  This is an example of reclaiming space where
the file  system has free space.  That filesystem is on a partition,
which is part of a logical volume.  We shrink from the inside
out - first the filesystem, then the partition, then the logical
volume.  If you don't have partitions within your LVs, skip that part.


#!/bin/sh


PATH="$PATH:/sbin:/root/bin"
export PATH

VG=bob

if [ -z "$2" ]
then
     echo "usage: $0 name size_in_gb (dh -h, NOT df -H)"
     exit
fi

name=$1
fssize=$2

echo "called clone_shrink $name $fssize"

kpartx -p '' -a /dev/mapper/${VG}-${name}
mount /dev/mapper/${VG}-${name}1 && sleep 2 &&
used=`df -P -BG | grep "$name" | awk '{ print \$3 }' | sed 's@G@@'` &&

if [ $used -gt $fssize ]
then
     echo "$name is using $used G, which is more than $fssize G" 1>&2
     exit 1
fi

/dev/mapper/${VG}-${name}1 &&
kpartx -dv -p '' /dev/mapper/${VG}-${name} && sleep 2 &&

# filesystem overhead
partsize=`perl -e "print int($fssize * 1.04)"` &&
vgsize=`expr $partsize + 1` &&


lvchange -ay $VG/$name &&
kpartx -p '' -a /dev/mapper/$VG-${name} &&
e2fsck -fp /dev/mapper/$VG-${name}1 2>/dev/null &&
resize2fs /dev/mapper/$VG-${name}1 ${fssize}G &&
e2fsck -fp /dev/mapper/$VG-${name}1 2>/dev/null
kpartx -p '' -d /dev/mapper/$VG-${name} &&
kpartx -p 'p' -d /dev/mapper/$VG-${name} &&

# If changing to parted or other, these are 1024 GB, not 1000 GB
lvchange -an $VG/$name &&
lvchange -ay $VG/$name &&
echo -e "d\nn\np\n1\n63\n+${partsize}GB\na\n1\np\nw\n | fdisk -u -S 63  
/dev/mapper/$VG-${name}"
echo -e "d\nn\np\n1\n63\n+${partsize}GB\na\n1\np\nw\n" | fdisk -u -S 63  
/dev/mapper/$VG-${name}
kpartx -p '' -d /dev/mapper/$VG-${name} &&
kpartx -p 'p' -d /dev/mapper/$VG-${name}


lvchange -an $VG/${name} &&
lvreduce -L ${vgsize}G $VG/${name} &&
lvchange -ay $VG/${name}

   The above commands are slightly adjusted from a script we use.
They may not be right for your situation.  They may not be right at all.
You should read and fully understand all commands before running them.

   Note particularly that due to overhead, 1000 vs. 1024, or other
reasons, the size of each container may need to be specified as being
a little larger than what it is supposed to contain.  Be very careful
when reducing the size of things - you could cut the end off of your
filesystems.  Also be sure you are familiar with vgcfgbackup,  
vgcfgrestore,
and other tools for undoing what you've done in case of problems.
--
Ray Morris
support@bettercgi.com

Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/

Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/

Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php


On 12/04/2010 12:06:46 PM, David Baron wrote:
> I need more extents to move stuff off older, possibly failing IDE  
> disks to my
> new SATA terrabyter. However, not enough extents are available. The  
> disk is
> very sparsely populated.
> 
> Is there any way to "condense" physical volumes to recover/expose  
> empty
> extents in order to make use of them?
> 
> _______________________________________________
> 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/
> 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-lvm] "Condensing" Physical Volumes
       [not found] <mailman.7913.1291608602.9820.linux-lvm@redhat.com>
@ 2010-12-06 12:34 ` David Baron
  0 siblings, 0 replies; 5+ messages in thread
From: David Baron @ 2010-12-06 12:34 UTC (permalink / raw)
  To: linux-lvm

On Monday 06 December 2010 06:10:02 linux-lvm-request@redhat.com wrote:
> > I need more extents to move stuff off older, possibly failing IDE disks
> > to my  new SATA terrabyter. However, not enough extents are available.
> > The disk is very sparsely populated.
> >
> > 
> >
> > Is there any way to "condense" physical volumes to recover/expose empty 
> > extents in order to make use of them?
>
>     Is your situation actually the following?:
> 
> The volume group is nearly full, meaning that most all
> of the extents are used by logical volumes.
> 
> On those logical volumes you have file systems.
> 
> Those file systems have free space.
> 
> If the above three conditions hold, you'd need to:
> 
> reduce the size of the file systems, perhaps using ex2resize.
> 
> Once each file system is reduced, you would then be able to reduce
> the logical volume which contains that filesystem.
> 
> That will mean there are free extents in the volume group, so you can
> then use pvmove to move the extents off of the chosen physical
> volumes.
That's about it.

Reducing the size of logical volumes was the first thing I thought of but it 
wants to umount them to do this--not so cool if they are /usr and stuff like 
that. I suppose this could be done using the Debian live CD.

Either /usr or /home could easily be shrunk leaving plenty of extents for the 
pieces still on an IDE disk.

> 
> Does pvmove --alloc anywhere help?
> 
> Alternatively, you can specify exactly which extents go where,
> like in "pvmove --test -n lvname.to.move /dev/pvold:20-27
> /dev/pvnew:732-739". obviously, remove --test, if it seems to do what you
> meant.
> 
> To see which what is where, and which extent ranges are free,
> I tend to use variants of
> pvs -o vg_name,lv_name,pv_name,pvseg_start,pvseg_size,seg_pe_ranges
> -Opv_name,pvseg_start Note that pe_ranges are inclusive, (end of the range
> is: pvseg_start  + pvseg_size -1).

I am not really conversant in the CLI tools so I do not know how to do this.

The only free exents are on a PV I created out of a partition which I had 
intended for another use. I pmoved the stuff from one of the IDE disks to this 
PV. A bit scary but worked fine despite problems with that IDE disk (which was 
then removed, thankfully).

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-12-06 12:34 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-04 18:06 [linux-lvm] "Condensing" Physical Volumes David Baron
2010-12-04 19:28 ` Ray Morris
2010-12-04 19:38 ` Lars Ellenberg
2010-12-04 19:40 ` Ray Morris
     [not found] <mailman.7913.1291608602.9820.linux-lvm@redhat.com>
2010-12-06 12:34 ` David Baron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).