[gentoo-user] LVM and LABELS in fstab

[gentoo-user] LVM and LABELS in fstab

[Dale]

OK.  I jumped into LVM.  I took my spare drive, put it to use with LVM.  
Then copied data from my super large drive to it and backed up some to 
DVDs that wouldn't fit.  Then I put the big drive on LVM and put the 
stuff back.  Now comes the problem.  I use LABELS in fstab and would 
like to continue that.  I can't figure out how to get the LABEL set for 
the LVM file system tho.  This is my info:

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 / # 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 / # 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 / #


I tried e2label since it has ext4 for the file system.  It didn't work 
and I don't know for sure what to point it to for the device.  I can't 
point to the drive itself since there are now two in the setup.

What am I missing here?  It's simple I'm sure but I'm missing it.

Dale

:-)  :-)

P. S.  hey, I got it all created, copied and all so it was a start. lol

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[Manuel McLure]

On Wed, Nov 16, 2011 at 6:52 PM, Dale <rdalek1967@gmail.com> wrote:
> OK.  I jumped into LVM.  I took my spare drive, put it to use with LVM.
>  Then copied data from my super large drive to it and backed up some to DVDs
> that wouldn't fit.  Then I put the big drive on LVM and put the stuff back.
>  Now comes the problem.  I use LABELS in fstab and would like to continue
> that.  I can't figure out how to get the LABEL set for the LVM file system
> tho.  This is my info:
>

...

> 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 / #
>
>
> I tried e2label since it has ext4 for the file system.  It didn't work and I
> don't know for sure what to point it to for the device.  I can't point to
> the drive itself since there are now two in the setup.
>
> What am I missing here?  It's simple I'm sure but I'm missing it.

You should be able to use e2label (or "tune2fs -L" as I do) on the
/dev/data/data1 device to set the filesystem label. That's the logical
volume that the operating system needs to mount.

# tune2fs -L mylabel /dev/data/data1

should do what you need.

I haven't done this with ext4, but I have used LVM with ext2, ext3 and
labels in this fashion.
-- 
Manuel A. McLure WW1FA <manuel@mclure.org> <http://www.mclure.org>
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.                       -- H.P. Lovecraft

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Manuel McLure wrote:
> You should be able to use e2label (or "tune2fs -L" as I do) on the 
> /dev/data/data1 device to set the filesystem label. That's the logical 
> volume that the operating system needs to mount. # tune2fs -L mylabel 
> /dev/data/data1 should do what you need. I haven't done this with 
> ext4, but I have used LVM with ext2, ext3 and labels in this fashion. 

That is the problem.  I was using e2label and got a error.  tune2fs 
worked fine.  I get this now:

root@fireball / # blkid /dev/mapper/data-data1
/dev/mapper/data-data1: UUID="7500437d-700c-4836-a878-29507af67a8d" 
TYPE="ext4" LABEL="data"
root@fireball / #

Sort of hard to believe I got this far with LVM tho.  I got some space now.

/dev/mapper/data-data1 960906608 255981512 656122832  29% /data

Now I can download some more of my TV shows.

One more question.  I have two drives.  A 250Gb and a 750Gb.  Originally 
the data was on the 750Gb drive.  I set the 250Gb up on LVM then moved 
things over from the 750Gb.  I then added the 750Gb to the VG and 
resized the file system.  So, in theory the data is on the 250Gb drive.  
Let's say I want to remove the 250Gb drive.  I would use pvmove to do 
that right?  When I ran pvmove /dev/sdb, which is the 250Gb drive, then 
it would remove all the data from that drive so that it could be 
removed.  Am I close?

I'm not planning to do that but just wanting to get a better 
understanding of this LVM thing.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[Florian Philipp]

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

Am 17.11.2011 07:50, schrieb Dale:
[...]
> One more question.  I have two drives.  A 250Gb and a 750Gb.  Originally
> the data was on the 750Gb drive.  I set the 250Gb up on LVM then moved
> things over from the 750Gb.  I then added the 750Gb to the VG and
> resized the file system.  So, in theory the data is on the 250Gb drive. 
> Let's say I want to remove the 250Gb drive.  I would use pvmove to do
> that right?  When I ran pvmove /dev/sdb, which is the 250Gb drive, then
> it would remove all the data from that drive so that it could be
> removed.  Am I close?
> 
> I'm not planning to do that but just wanting to get a better
> understanding of this LVM thing.
> 
> Dale
> 

Yes, that is correct. It moves the data by mirroring it temporarily on
the new location before updating the metadata so that only the new
location is used. Therefore you can safely reboot or abort operations.

Regards,
Florian Philipp



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

Re: [gentoo-user] LVM and LABELS in fstab

[Joost Roeleveld]

On Thursday, November 17, 2011 10:43:28 AM Florian Philipp wrote:
> Am 17.11.2011 07:50, schrieb Dale:
> [...]
> 
> > One more question.  I have two drives.  A 250Gb and a 750Gb.  Originally
> > the data was on the 750Gb drive.  I set the 250Gb up on LVM then moved
> > things over from the 750Gb.  I then added the 750Gb to the VG and
> > resized the file system.  So, in theory the data is on the 250Gb drive.
> > Let's say I want to remove the 250Gb drive.  I would use pvmove to do
> > that right?  When I ran pvmove /dev/sdb, which is the 250Gb drive, then
> > it would remove all the data from that drive so that it could be
> > removed.  Am I close?
> > 
> > I'm not planning to do that but just wanting to get a better
> > understanding of this LVM thing.
> > 
> > Dale
> 
> Yes, that is correct. It moves the data by mirroring it temporarily on
> the new location before updating the metadata so that only the new
> location is used. Therefore you can safely reboot or abort operations.

Also, this will only work if the VG has sufficient unused space (eg. not used 
by LVs) on the other disk(s) to accomodate the data moved.

--
Joost

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Joost Roeleveld wrote:
> On Thursday, November 17, 2011 10:43:28 AM Florian Philipp wrote:
>> Am 17.11.2011 07:50, schrieb Dale:
>> [...]
>>
>>> One more question.  I have two drives.  A 250Gb and a 750Gb.  Originally
>>> the data was on the 750Gb drive.  I set the 250Gb up on LVM then moved
>>> things over from the 750Gb.  I then added the 750Gb to the VG and
>>> resized the file system.  So, in theory the data is on the 250Gb drive.
>>> Let's say I want to remove the 250Gb drive.  I would use pvmove to do
>>> that right?  When I ran pvmove /dev/sdb, which is the 250Gb drive, then
>>> it would remove all the data from that drive so that it could be
>>> removed.  Am I close?
>>>
>>> I'm not planning to do that but just wanting to get a better
>>> understanding of this LVM thing.
>>>
>>> Dale
>> Yes, that is correct. It moves the data by mirroring it temporarily on
>> the new location before updating the metadata so that only the new
>> location is used. Therefore you can safely reboot or abort operations.
> Also, this will only work if the VG has sufficient unused space (eg. not used
> by LVs) on the other disk(s) to accomodate the data moved.
>
> --
> Joost
>
>


Thanks.  Clear as mud now.   lol  I'm getting there.  Is there a tool to 
see if there is enough room to do this before trying it?

Curious about gkrellm and how it will see the new drives now.  May be 
interesting.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[Neil Bothwick]

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

On Thu, 17 Nov 2011 11:37:59 -0600, Dale wrote:

> > Also, this will only work if the VG has sufficient unused space (eg.
> > not used by LVs) on the other disk(s) to accomodate the data moved.

> Thanks.  Clear as mud now.   lol  I'm getting there.  Is there a tool
> to see if there is enough room to do this before trying it?

pvs, vgs and lvs are your friends here. As long as the free space
reported by vgs is more than pvs reports as the size of the partition you
want to remove, you will be fine.

Although pvmove will also let you know if there isn't enough space for
what you want.


-- 
Neil Bothwick

Everyone has a photographic memory. Some don't have film.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Neil Bothwick wrote:
> On Thu, 17 Nov 2011 11:37:59 -0600, Dale wrote:
>
>>> Also, this will only work if the VG has sufficient unused space (eg.
>>> not used by LVs) on the other disk(s) to accomodate the data moved.
>> Thanks.  Clear as mud now.   lol  I'm getting there.  Is there a tool
>> to see if there is enough room to do this before trying it?
> pvs, vgs and lvs are your friends here. As long as the free space
> reported by vgs is more than pvs reports as the size of the partition you
> want to remove, you will be fine.
>
> Although pvmove will also let you know if there isn't enough space for
> what you want.
>
>

I found something that is a bit annoying here.  I have gkrellm running 
on my desktop to sort of keep a eye on things.  This works fine for the 
little part down at the bottom with how much is used and how much is 
free.  Thing is, the part that shows activity doesn't have anything for 
LVM.  I have the listing for the individual drives, sdb and sdc, but 
nothing for the whole thing.

Is there a way to make this work?  I googled but I couldn't find 
anything on this one.  Well, a few worthless hits that just happen to 
have the words on the same page for some reason.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[James Wall]

On Thu, Nov 17, 2011 at 11:18 PM, Dale <rdalek1967@gmail.com> wrote:
> Neil Bothwick wrote:
>>
>> On Thu, 17 Nov 2011 11:37:59 -0600, Dale wrote:
>>
>>>> Also, this will only work if the VG has sufficient unused space (eg.
>>>> not used by LVs) on the other disk(s) to accomodate the data moved.
>>>
>>> Thanks.  Clear as mud now.   lol  I'm getting there.  Is there a tool
>>> to see if there is enough room to do this before trying it?
>>
>> pvs, vgs and lvs are your friends here. As long as the free space
>> reported by vgs is more than pvs reports as the size of the partition you
>> want to remove, you will be fine.
>>
>> Although pvmove will also let you know if there isn't enough space for
>> what you want.
>>
>>
>
> I found something that is a bit annoying here.  I have gkrellm running on my
> desktop to sort of keep a eye on things.  This works fine for the little
> part down at the bottom with how much is used and how much is free.  Thing
> is, the part that shows activity doesn't have anything for LVM.  I have the
> listing for the individual drives, sdb and sdc, but nothing for the whole
> thing.
>
> Is there a way to make this work?  I googled but I couldn't find anything on
> this one.  Well, a few worthless hits that just happen to have the words on
> the same page for some reason.

Look for /dev/dm-0 to monitor your lvm partition. that is what I use
to monitor my LVM /, swap, and /home partitions in the monitor setup.
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or how
> you interpreted my words!
>
>
>



-- 
No trees were harmed in the sending of this message. However, a large
number of electrons were terribly inconvenienced.

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

James Wall wrote:
> On Thu, Nov 17, 2011 at 11:18 PM, Dale<rdalek1967@gmail.com>  wrote:
>> Is there a way to make this work?  I googled but I couldn't find anything on
>> this one.  Well, a few worthless hits that just happen to have the words on
>> the same page for some reason.
> Look for /dev/dm-0 to monitor your lvm partition. that is what I use
> to monitor my LVM /, swap, and /home partitions in the monitor setup.
>> Dale
>>
>> :-)  :-)
>>
>>

I don't see that option here.  All I have is sd* and sr0.  Also 
composite for all drives.

[ebuild   R    ] app-admin/gkrellm-2.3.5  USE="X hddtemp nls ssl -gnutls 
-lm_sensors -ntlm"

Your flags look something like mine?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[James Wall]

On Sun, Nov 20, 2011 at 2:32 PM, Dale <rdalek1967@gmail.com> wrote:
> James Wall wrote:
>>
>> On Thu, Nov 17, 2011 at 11:18 PM, Dale<rdalek1967@gmail.com>  wrote:
>>>
>>> Is there a way to make this work?  I googled but I couldn't find anything
>>> on
>>> this one.  Well, a few worthless hits that just happen to have the words
>>> on
>>> the same page for some reason.
>>
>> Look for /dev/dm-0 to monitor your lvm partition. that is what I use
>> to monitor my LVM /, swap, and /home partitions in the monitor setup.
>>>
>>> Dale
>>>
>>> :-)  :-)
>>>
>>>
>
> I don't see that option here.  All I have is sd* and sr0.  Also composite
> for all drives.
>
> [ebuild   R    ] app-admin/gkrellm-2.3.5  USE="X hddtemp nls ssl -gnutls
> -lm_sensors -ntlm"

My use flags are
[ebuild   R    ] app-admin/gkrellm-2.3.5  USE="X nls ssl -gnutls
-hddtemp -lm_sensors -ntlm"
Hope this helps,
James Wall

> Your flags look something like mine?
>
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or how
> you interpreted my words!
>
>
>



-- 
No trees were harmed in the sending of this message. However, a large
number of electrons were terribly inconvenienced.

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Another LVM question.  If I want to remove a drive and tell pvmove to 
move the data off it, can the drive have files being written to it while 
this is done?  I'm wanting to use my old spare drive to move some things 
around but right now LVM has it.  I think it is OK but just want to make 
sure.  If it is not OK, do I have to unmount the LV first?

Thanks.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[Neil Bothwick]

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

On Tue, 22 Nov 2011 23:50:08 -0600, Dale wrote:

> Another LVM question.  If I want to remove a drive and tell pvmove to 
> move the data off it, can the drive have files being written to it
> while this is done?  I'm wanting to use my old spare drive to move some
> things around but right now LVM has it.  I think it is OK but just want
> to make sure.  If it is not OK, do I have to unmount the LV first?

Once you start pvmove running, LVM will not allocate any more space on
the drive, so any files written to the LV will go on another drive.

If you mean you want to write to it separately from LVM, of course you
can, as long as you are using a different partition.


-- 
Neil Bothwick

WinErr 007: System price error - Inadequate money spent on hardware

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Neil Bothwick wrote:
> On Tue, 22 Nov 2011 23:50:08 -0600, Dale wrote:
>
>> Another LVM question.  If I want to remove a drive and tell pvmove to
>> move the data off it, can the drive have files being written to it
>> while this is done?  I'm wanting to use my old spare drive to move some
>> things around but right now LVM has it.  I think it is OK but just want
>> to make sure.  If it is not OK, do I have to unmount the LV first?
> Once you start pvmove running, LVM will not allocate any more space on
> the drive, so any files written to the LV will go on another drive.
>
> If you mean you want to write to it separately from LVM, of course you
> can, as long as you are using a different partition.
>
>

I think we have a problem:

root@fireball / # pvmove -v /dev/sdb1
     Finding volume group "data"
     Archiving volume group "data" metadata (seqno 4).
     Creating logical volume pvmove0
     Moving 59604 extents of logical volume data/data1
   Insufficient free space: 59604 extents needed, but only 118 available
   Unable to allocate mirror extents for pvmove0.
   Failed to convert pvmove LV to mirrored
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 / # df
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                19534436   7249460  12284976  38% /
/dev/root             19534436   7249460  12284976  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   4366692   4759052  48% /var
/dev/sda6             11535344   5332948   5616428  49% /usr/portage
/dev/sda7             48828008  11273180  37554828  24% /home
/dev/mapper/data-data1
                      960906608 275263224 636841120  31% /data
tmpfs                  8232972         0   8232972   0% /var/tmp/portage
/dev/sda9             59434744  31373872  25041732  56% /mnt/temp
root@fireball / #


So, I got space left on sdc but it won't move the data off sdb.  Did 
this run off into the ditch?  :/

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[Neil Bothwick]

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

On Wed, 23 Nov 2011 13:07:55 -0600, Dale wrote:

> I think we have a problem:
> 
> root@fireball / # pvmove -v /dev/sdb1
>      Finding volume group "data"
>      Archiving volume group "data" metadata (seqno 4).
>      Creating logical volume pvmove0
>      Moving 59604 extents of logical volume data/data1
>    Insufficient free space: 59604 extents needed, but only 118 available
>    Unable to allocate mirror extents for pvmove0.
>    Failed to convert pvmove LV to mirrored
> 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

You need to move 59604 extents but you only have 116 free on the
destination.

> root@fireball / # df
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/mapper/data-data1
>                       960906608 275263224 636841120  31% /data

> So, I got space left on sdc but it won't move the data off sdb.  Did 
> this run off into the ditch?  :/

You have space in the filesystem, but the volume containing that
filesystem is too large to move. You must first reduce the filesystem
size, with resize2fs or whatever suits your fs, then shrink the LV with
lvresize. That will free up enough extents to be able to fit them all on
one disk.

Look at the output from lvs to see what is taking up all the space.


-- 
Neil Bothwick

Men who have playful kittens shouldn't sleep in the nude.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Neil Bothwick wrote:
> You have space in the filesystem, but the volume containing that 
> filesystem is too large to move. You must first reduce the filesystem 
> size, with resize2fs or whatever suits your fs, then shrink the LV 
> with lvresize. That will free up enough extents to be able to fit them 
> all on one disk. Look at the output from lvs to see what is taking up 
> all the space. 

So, me staring at it a while and trying to figure it out did work.  That 
is what I was thinking.  Thing is, it looks to me like it would just 
move the stuff over then I can reduce it by what sdb is making for its 
share.  Although, their way makes sense too.

I basically need to reduce the thing by 59604 PEs then it can move them 
over to sdc so I can remove sdb.  Looks like I am about to really learn 
something here.  It uses ext4 by the way.  Looks like adding is easier 
than removing, sort of.

Now to get my ducks in a row.  o_O

Thanks.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Dale wrote:
> Neil Bothwick wrote:
>> You have space in the filesystem, but the volume containing that 
>> filesystem is too large to move. You must first reduce the filesystem 
>> size, with resize2fs or whatever suits your fs, then shrink the LV 
>> with lvresize. That will free up enough extents to be able to fit 
>> them all on one disk. Look at the output from lvs to see what is 
>> taking up all the space. 
>
> So, me staring at it a while and trying to figure it out did work.  
> That is what I was thinking.  Thing is, it looks to me like it would 
> just move the stuff over then I can reduce it by what sdb is making 
> for its share.  Although, their way makes sense too.
>
> I basically need to reduce the thing by 59604 PEs then it can move 
> them over to sdc so I can remove sdb.  Looks like I am about to really 
> learn something here.  It uses ext4 by the way.  Looks like adding is 
> easier than removing, sort of.
>
> Now to get my ducks in a row.  o_O
>
> Thanks.
>
> Dale
>
> :-)  :-)
>


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.

Thanks.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[Alex Schuster]

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

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

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!

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Dale wrote:
>
> 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
>

For some poor soul that is as new to LVM as I am.  Here is the commands 
I ended up using:

umount /data
e2fsck -f /dev/mapper/data-data1
resize2fs /dev/mapper/data-data1 400G
lvreduce -L 400G /dev/data/data1
pvmove -v /dev/sdb1


I did have to unmount it first.  It just wouldn't proceed without that 
one.  It then told me I had to run fsck on it too.  Other than that, it 
seems to have worked fine.

Now to figure out a few other things.  I may be back.  o_O

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] LVM and LABELS in fstab

[Neil Bothwick]

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

On Thu, 24 Nov 2011 04:48:28 -0600, Dale wrote:

> umount /data
> e2fsck -f /dev/mapper/data-data1
> resize2fs /dev/mapper/data-data1 400G
> lvreduce -L 400G /dev/data/data1
> pvmove -v /dev/sdb1

I feel safer reducing the filesystem to smaller than the intended
partition/LV size, just in case, and resizing it back up after.

resize2fs /dev/mapper/data-data1 390G
lvreduce -L 400G /dev/data/data1
resize2fs /dev/mapper/data-data1

> I did have to unmount it first.  It just wouldn't proceed without that 
> one.  It then told me I had to run fsck on it too.

Those are both from resize2fs, once you have run that, you can remount the
filesystem.


-- 
Neil Bothwick

...and that is how we know the Earth to be banana-shaped.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] LVM and LABELS in fstab

[Alan McKinnon]

On Wed, 23 Nov 2011 21:28:56 -0600
Dale <rdalek1967@gmail.com> wrote:

> Dale wrote:
> > Neil Bothwick wrote:
> >> You have space in the filesystem, but the volume containing that 
> >> filesystem is too large to move. You must first reduce the
> >> filesystem size, with resize2fs or whatever suits your fs, then
> >> shrink the LV with lvresize. That will free up enough extents to
> >> be able to fit them all on one disk. Look at the output from lvs
> >> to see what is taking up all the space. 
> >
> > So, me staring at it a while and trying to figure it out did work.  
> > That is what I was thinking.  Thing is, it looks to me like it
> > would just move the stuff over then I can reduce it by what sdb is
> > making for its share.  Although, their way makes sense too.
> >
> > I basically need to reduce the thing by 59604 PEs then it can move 
> > them over to sdc so I can remove sdb.  Looks like I am about to
> > really learn something here.  It uses ext4 by the way.  Looks like
> > adding is easier than removing, sort of.
> >
> > Now to get my ducks in a row.  o_O
> >
> > Thanks.
> >
> > Dale
> >
> > :-)  :-)
> >
> 
> 
> 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, not quite. You're on the right track but got some of the details
wrong. Let's look first at the layers of stuff involved:


   files & directories

   file system

   logical volume (LV)

   volume group (VG)

   physical volume (PV)  

   physical partition    (i.e. /dev/sda1 etc)

   physical disk         (i.e. something Seagate etc made)



OK, there's a lot of stuff there. When you made the LV, you worked from
the bottom up. To undo it, you work from the top down. And the
important bit:

Everything in that list only knows about the one directly below it.

The other important bit:

Nothing in that list can be bigger than the thing below it.

This makes perfect sense: You can't store a 5G file on a 4G
file-system, nor can you create a 1TB partition on a 500G disk.


Tools like lv* only know about LVs and how they are built, it's
clueless about the actual files and filesystems involved. So when you
want to move things around, the tool will look at the volume and see
how many extents it uses. It will want to move all those extents
somewhere else.

Now say you made a 40G filesystem on an LV but only have 500M of
actual files on it. LVM tools are going to want to move a 40G volume,
never mind that 39.5G of it is unused. If you don't have 40G of free
space, you have to start juggling.

First get the filesystem down to a reasonable size:

1. Shrink the filesystem using resize2fs, resize_reiserfs etc.
2. lvreduce to make the logical volume match the file system.

Now you have a 500M thing to move around and your life gets easier.

What you want to accomplish is to move all the LVs from one disk to
another disk, you need to have enough free space on the new PV to hold
all those LVs. When you've done that the old PV will now have no data
on it (none of it's extents will be in use), you can remove it from the
VG, then delete the PV, and finally remove the disk from the machine.

*fdisk is the only truly destructive tool in your toolbox, the LVM
tools will all give you errors if you try and remove things that are in
use or if there's not enough free space.

There's no easy recipes for this that you can just follow. You need to
understand the things you are dealing with and know what they are. But
it's not *that* hard.

Like most things in Linux, LVM assumes that you, Dale, are probably not
a complete idiot and that you do know what you are doing. That's why
are the gory details are exposed for you to play with.

Now if it were Windows and you were extremely lucky, you might get a
GUI thingy that let's you drag an bunch of unnamed stuff from here and
put it there. Which would promptly fail, silently.





-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] LVM and LABELS in fstab

[Dale]

Alan McKinnon wrote:
> On Wed, 23 Nov 2011 21:28:56 -0600
> Dale<rdalek1967@gmail.com>  wrote:
>
>> Dale wrote:
>>> Neil Bothwick wrote:
>>>> You have space in the filesystem, but the volume containing that
>>>> filesystem is too large to move. You must first reduce the
>>>> filesystem size, with resize2fs or whatever suits your fs, then
>>>> shrink the LV with lvresize. That will free up enough extents to
>>>> be able to fit them all on one disk. Look at the output from lvs
>>>> to see what is taking up all the space.
>>> So, me staring at it a while and trying to figure it out did work.
>>> That is what I was thinking.  Thing is, it looks to me like it
>>> would just move the stuff over then I can reduce it by what sdb is
>>> making for its share.  Although, their way makes sense too.
>>>
>>> I basically need to reduce the thing by 59604 PEs then it can move
>>> them over to sdc so I can remove sdb.  Looks like I am about to
>>> really learn something here.  It uses ext4 by the way.  Looks like
>>> adding is easier than removing, sort of.
>>>
>>> Now to get my ducks in a row.  o_O
>>>
>>> Thanks.
>>>
>>> Dale
>>>
>>> :-)  :-)
>>>
>>
>> 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, not quite. You're on the right track but got some of the details
> wrong. Let's look first at the layers of stuff involved:
>
>
>     files&  directories
>
>     file system
>
>     logical volume (LV)
>
>     volume group (VG)
>
>     physical volume (PV)
>
>     physical partition    (i.e. /dev/sda1 etc)
>
>     physical disk         (i.e. something Seagate etc made)
>
>
>
> OK, there's a lot of stuff there. When you made the LV, you worked from
> the bottom up. To undo it, you work from the top down. And the
> important bit:
>
> Everything in that list only knows about the one directly below it.
>
> The other important bit:
>
> Nothing in that list can be bigger than the thing below it.
>
> This makes perfect sense: You can't store a 5G file on a 4G
> file-system, nor can you create a 1TB partition on a 500G disk.
>
>
> Tools like lv* only know about LVs and how they are built, it's
> clueless about the actual files and filesystems involved. So when you
> want to move things around, the tool will look at the volume and see
> how many extents it uses. It will want to move all those extents
> somewhere else.
>
> Now say you made a 40G filesystem on an LV but only have 500M of
> actual files on it. LVM tools are going to want to move a 40G volume,
> never mind that 39.5G of it is unused. If you don't have 40G of free
> space, you have to start juggling.
>
> First get the filesystem down to a reasonable size:
>
> 1. Shrink the filesystem using resize2fs, resize_reiserfs etc.
> 2. lvreduce to make the logical volume match the file system.
>
> Now you have a 500M thing to move around and your life gets easier.
>
> What you want to accomplish is to move all the LVs from one disk to
> another disk, you need to have enough free space on the new PV to hold
> all those LVs. When you've done that the old PV will now have no data
> on it (none of it's extents will be in use), you can remove it from the
> VG, then delete the PV, and finally remove the disk from the machine.
>
> *fdisk is the only truly destructive tool in your toolbox, the LVM
> tools will all give you errors if you try and remove things that are in
> use or if there's not enough free space.
>
> There's no easy recipes for this that you can just follow. You need to
> understand the things you are dealing with and know what they are. But
> it's not *that* hard.
>
> Like most things in Linux, LVM assumes that you, Dale, are probably not
> a complete idiot and that you do know what you are doing. That's why
> are the gory details are exposed for you to play with.
>
> Now if it were Windows and you were extremely lucky, you might get a
> GUI thingy that let's you drag an bunch of unnamed stuff from here and
> put it there. Which would promptly fail, silently.
>
>

I think I had a light bulb moment but I plan to read this a few more 
times.  I have these two drives, sdb and sdc, that are in the LVM 
system.  I want to remove sdb, the smaller one, and when I do pvmove it 
doesn't move the files, it doesn't even see the files themselves, it 
sort of moves the file system itself which just happens to take the 
files with it.  It takes the same amount of time even if there are no 
files on it.  Sort of like dd does in a way.  dd doesn't see files or 
anything, it just copies the bits on the platter.

Am I getting close here?

You didn't really bring up winders did you?  You do know I hate 
winders.  The only windows I like lets fresh are in when spring comes.  ;-)

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!