From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-131439-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1RTR4Y-00072a-9c
for garchives@archives.gentoo.org; Thu, 24 Nov 2011 04:38:06 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 38A2B21C03A;
Thu, 24 Nov 2011 04:37:57 +0000 (UTC)
Received: from mail-gy0-f181.google.com (mail-gy0-f181.google.com [209.85.160.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 3B5AB21C01F
for <gentoo-user@lists.gentoo.org>; Thu, 24 Nov 2011 04:37:04 +0000 (UTC)
Received: by ghrr13 with SMTP id r13so2791616ghr.40
for <gentoo-user@lists.gentoo.org>; Wed, 23 Nov 2011 20:37:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=Wl5SLVBsTqIcb/l1wPMKAIG8muu/Q9ZkhOtjm9dvbxU=;
b=vfkwol91xUDrPYerrxeQQDXUXAjn1sZ5YY4QQ6yiBPQq9kEYw67aIx/XUK+f3dP4yk
LqNeHg+PHGxP8hseDNqajj7Inew1Com8dzTKrQhhtL2NpyWpOM9AuX2RoJXs1QulS/Ie
5zwT3zwcnICwPZgbcsSXpZVlDBktMI1FpW7CE=
Received: by 10.236.155.36 with SMTP id i24mr29437594yhk.43.1322109423724;
Wed, 23 Nov 2011 20:37:03 -0800 (PST)
Received: from [192.168.2.5] (adsl-65-0-66-118.jan.bellsouth.net. [65.0.66.118])
by mx.google.com with ESMTPS id i31sm54685717anm.19.2011.11.23.20.37.01
(version=SSLv3 cipher=OTHER);
Wed, 23 Nov 2011 20:37:02 -0800 (PST)
Message-ID: <4ECDC9EC.1090404@gmail.com>
Date: Wed, 23 Nov 2011 22:37:00 -0600
From: Dale <rdalek1967@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111022 Firefox/7.0.1 SeaMonkey/2.4.1
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] LVM and LABELS in fstab
References: <4EC47700.2060707@gmail.com> <4ECC8990.7080106@gmail.com> <20111123133116.5cf32784@hactar.digimed.co.uk> <4ECD448B.3050603@gmail.com> <20111123211729.62c264cd@digimed.co.uk> <4ECD9D9A.4030908@gmail.com> <4ECDB9F8.30006@gmail.com> <4ECDC266.1040101@wonkology.org>
In-Reply-To: <4ECDC266.1040101@wonkology.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Archives-Salt: dd404f0e-9acd-4a60-b3a3-b9b889f67c03
X-Archives-Hash: 75edf31c87275956b6a58511457e252e
Alex Schuster wrote:
> Dale asks:
>
>> OK. Everyone duck, I been thinking on this and Neils info above. lol
>> This is what I sort of figured out and tell me where I am off here. I
>> have to reduce the file system, change the partition in cfdisk (?),
>> resize the lv, then reduce the vg, then I can run pvmove? After all
>> that, I can remove the drive sdb? Do I have the order correct too? If
>> it does involve all this, I'm not sure I want to do this. The file
>> system and cfdisk part makes me nervous. Maybe some of this isn't
>> needed and I am reading some of the info incorrectly, I hope.
> No need for cfdisk. Just shrink the file system, and then the logical
> volume. You can keep the VG as it is, as you move stuff around inside
> the same VG. BTW, I also tend to make lots of partitions on a drive, all
> belonging to the same VG, so I can more easily change things later. Like
> freeing a partition in case some other OS needs space for itself or
> something like that.
> I tend to shrink the file system to a size somewhat smaller than the
> logical volume, just in case there is some additional header or
> something, or different utilities use different units (megabytes vs.
> mibibytes). Calling resize2fs afterwards enlarges the FS to the maximum
> size.
>
> I wrote a script to automate this, it also takes care of a LUKS volume
> on the LVM. And is easier to use than doing all those steps in a row.
> And I trust it more than me making a typo in one of those commands. But
> I don't think I would use such a thing written by some guy, and prefer
> to just do it myself.
>
> Wonko
>
>
Whew!! I'm glad cfdisk and such isn't in this. I read a thing
somewhere that was talking about calculating blocks and such and I
didn't want to go down that road. I have Kcalc on here but still.
So, the commands is something like this:
resize2fs /dev/mapper/data-data1 400G < this should make the VG a
absolute size of 400Gbs which leaves a little room left over. If I used
a - in front, it would reduce by that amount. >
lvreduce -L 400G /dev/data/data1 < I assume I can make this the same
size as above? >
pvmove -v /dev/sdb1
pvremove /dev/sdb1
Showing info for clarity here:
root@fireball / # df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 19534436 7249480 12284956 38% /
/dev/root 19534436 7249480 12284956 38% /
rc-svcdir 1024 120 904 12% /lib64/rc/init.d
udev 10240 360 9880 4% /dev
shm 8232972 0 8232972 0% /dev/shm
/dev/sda1 186663 28128 148898 16% /boot
/dev/sda8 9614116 4366728 4759016 48% /var
/dev/sda6 11535344 5332948 5616428 49% /usr/portage
/dev/sda7 48828008 11273208 37554800 24% /home
/dev/mapper/data-data1
960906608 276328616 635775728 31% /data
tmpfs 8232972 0 8232972 0% /var/tmp/portage
/dev/sda9 59434744 31373872 25041732 56% /mnt/temp
root@fireball / # lvdisplay
--- Logical volume ---
LV Name /dev/data/data1
VG Name data
LV UUID ZvsgH6-PI0M-NqVd-op9P-Crsy-IEnz-iKoTfp
LV Write Access read/write
LV Status available
# open 1
LV Size 931.00 GiB
Current LE 238336
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0
root@fireball / # vgdisplay
--- Volume group ---
VG Name data
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 931.46 GiB
PE Size 4.00 MiB
Total PE 238454
Alloc PE / Size 238336 / 931.00 GiB
Free PE / Size 118 / 472.00 MiB
VG UUID eNF7B0-3BDb-qe1W-5FTH-4Uah-wRe1-xD7Xa8
root@fireball / # pvdisplay
--- Physical volume ---
PV Name /dev/sdb1
VG Name data
PV Size 232.83 GiB / not usable 2.55 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 59604
Free PE 0
Allocated PE 59604
PV UUID Nxvrjn-BuaK-RGsF-F32S-0EaI-W4xe-H6Lnjl
--- Physical volume ---
PV Name /dev/sdc1
VG Name data
PV Size 698.64 GiB / not usable 4.84 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 178850
Free PE 118
Allocated PE 178732
PV UUID NF6I4G-L1L5-0VDE-HyUc-ESH3-CfV3-eUo676
root@fireball / #
Now for my piece of mind. When I run pvmove, does it move the file
system over to take up the extra space or does it copy the individual
files over? I was thinking the latter but it seems it is more like the
former.
Do I have to run anything after pvmove or will the data still show up on
/dev/data/data1 like it is now? Will the move make it take up the extra
space on sdc1 that I had to clear off above basically?
As you can tell, I'm still trying to get a good picture in my head of
how this works. Thanks to all for helping with the paint brushes. ;-)
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!