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!


Reply via email to