| 1 |
Alex Schuster wrote: |
| 2 |
> Dale asks: |
| 3 |
> |
| 4 |
>> OK. Everyone duck, I been thinking on this and Neils info above. lol |
| 5 |
>> This is what I sort of figured out and tell me where I am off here. I |
| 6 |
>> have to reduce the file system, change the partition in cfdisk (?), |
| 7 |
>> resize the lv, then reduce the vg, then I can run pvmove? After all |
| 8 |
>> that, I can remove the drive sdb? Do I have the order correct too? If |
| 9 |
>> it does involve all this, I'm not sure I want to do this. The file |
| 10 |
>> system and cfdisk part makes me nervous. Maybe some of this isn't |
| 11 |
>> needed and I am reading some of the info incorrectly, I hope. |
| 12 |
> No need for cfdisk. Just shrink the file system, and then the logical |
| 13 |
> volume. You can keep the VG as it is, as you move stuff around inside |
| 14 |
> the same VG. BTW, I also tend to make lots of partitions on a drive, all |
| 15 |
> belonging to the same VG, so I can more easily change things later. Like |
| 16 |
> freeing a partition in case some other OS needs space for itself or |
| 17 |
> something like that. |
| 18 |
> I tend to shrink the file system to a size somewhat smaller than the |
| 19 |
> logical volume, just in case there is some additional header or |
| 20 |
> something, or different utilities use different units (megabytes vs. |
| 21 |
> mibibytes). Calling resize2fs afterwards enlarges the FS to the maximum |
| 22 |
> size. |
| 23 |
> |
| 24 |
> I wrote a script to automate this, it also takes care of a LUKS volume |
| 25 |
> on the LVM. And is easier to use than doing all those steps in a row. |
| 26 |
> And I trust it more than me making a typo in one of those commands. But |
| 27 |
> I don't think I would use such a thing written by some guy, and prefer |
| 28 |
> to just do it myself. |
| 29 |
> |
| 30 |
> Wonko |
| 31 |
> |
| 32 |
> |
| 33 |
|
| 34 |
|
| 35 |
Whew!! I'm glad cfdisk and such isn't in this. I read a thing |
| 36 |
somewhere that was talking about calculating blocks and such and I |
| 37 |
didn't want to go down that road. I have Kcalc on here but still. |
| 38 |
|
| 39 |
So, the commands is something like this: |
| 40 |
|
| 41 |
resize2fs /dev/mapper/data-data1 400G < this should make the VG a |
| 42 |
absolute size of 400Gbs which leaves a little room left over. If I used |
| 43 |
a - in front, it would reduce by that amount. > |
| 44 |
lvreduce -L 400G /dev/data/data1 < I assume I can make this the same |
| 45 |
size as above? > |
| 46 |
pvmove -v /dev/sdb1 |
| 47 |
pvremove /dev/sdb1 |
| 48 |
|
| 49 |
Showing info for clarity here: |
| 50 |
|
| 51 |
root@fireball / # df |
| 52 |
Filesystem 1K-blocks Used Available Use% Mounted on |
| 53 |
rootfs 19534436 7249480 12284956 38% / |
| 54 |
/dev/root 19534436 7249480 12284956 38% / |
| 55 |
rc-svcdir 1024 120 904 12% /lib64/rc/init.d |
| 56 |
udev 10240 360 9880 4% /dev |
| 57 |
shm 8232972 0 8232972 0% /dev/shm |
| 58 |
/dev/sda1 186663 28128 148898 16% /boot |
| 59 |
/dev/sda8 9614116 4366728 4759016 48% /var |
| 60 |
/dev/sda6 11535344 5332948 5616428 49% /usr/portage |
| 61 |
/dev/sda7 48828008 11273208 37554800 24% /home |
| 62 |
/dev/mapper/data-data1 |
| 63 |
960906608 276328616 635775728 31% /data |
| 64 |
tmpfs 8232972 0 8232972 0% /var/tmp/portage |
| 65 |
/dev/sda9 59434744 31373872 25041732 56% /mnt/temp |
| 66 |
root@fireball / # lvdisplay |
| 67 |
--- Logical volume --- |
| 68 |
LV Name /dev/data/data1 |
| 69 |
VG Name data |
| 70 |
LV UUID ZvsgH6-PI0M-NqVd-op9P-Crsy-IEnz-iKoTfp |
| 71 |
LV Write Access read/write |
| 72 |
LV Status available |
| 73 |
# open 1 |
| 74 |
LV Size 931.00 GiB |
| 75 |
Current LE 238336 |
| 76 |
Segments 2 |
| 77 |
Allocation inherit |
| 78 |
Read ahead sectors auto |
| 79 |
- currently set to 256 |
| 80 |
Block device 254:0 |
| 81 |
|
| 82 |
root@fireball / # vgdisplay |
| 83 |
--- Volume group --- |
| 84 |
VG Name data |
| 85 |
System ID |
| 86 |
Format lvm2 |
| 87 |
Metadata Areas 2 |
| 88 |
Metadata Sequence No 4 |
| 89 |
VG Access read/write |
| 90 |
VG Status resizable |
| 91 |
MAX LV 0 |
| 92 |
Cur LV 1 |
| 93 |
Open LV 1 |
| 94 |
Max PV 0 |
| 95 |
Cur PV 2 |
| 96 |
Act PV 2 |
| 97 |
VG Size 931.46 GiB |
| 98 |
PE Size 4.00 MiB |
| 99 |
Total PE 238454 |
| 100 |
Alloc PE / Size 238336 / 931.00 GiB |
| 101 |
Free PE / Size 118 / 472.00 MiB |
| 102 |
VG UUID eNF7B0-3BDb-qe1W-5FTH-4Uah-wRe1-xD7Xa8 |
| 103 |
|
| 104 |
root@fireball / # pvdisplay |
| 105 |
--- Physical volume --- |
| 106 |
PV Name /dev/sdb1 |
| 107 |
VG Name data |
| 108 |
PV Size 232.83 GiB / not usable 2.55 MiB |
| 109 |
Allocatable yes (but full) |
| 110 |
PE Size 4.00 MiB |
| 111 |
Total PE 59604 |
| 112 |
Free PE 0 |
| 113 |
Allocated PE 59604 |
| 114 |
PV UUID Nxvrjn-BuaK-RGsF-F32S-0EaI-W4xe-H6Lnjl |
| 115 |
|
| 116 |
--- Physical volume --- |
| 117 |
PV Name /dev/sdc1 |
| 118 |
VG Name data |
| 119 |
PV Size 698.64 GiB / not usable 4.84 MiB |
| 120 |
Allocatable yes |
| 121 |
PE Size 4.00 MiB |
| 122 |
Total PE 178850 |
| 123 |
Free PE 118 |
| 124 |
Allocated PE 178732 |
| 125 |
PV UUID NF6I4G-L1L5-0VDE-HyUc-ESH3-CfV3-eUo676 |
| 126 |
|
| 127 |
root@fireball / # |
| 128 |
|
| 129 |
|
| 130 |
Now for my piece of mind. When I run pvmove, does it move the file |
| 131 |
system over to take up the extra space or does it copy the individual |
| 132 |
files over? I was thinking the latter but it seems it is more like the |
| 133 |
former. |
| 134 |
|
| 135 |
Do I have to run anything after pvmove or will the data still show up on |
| 136 |
/dev/data/data1 like it is now? Will the move make it take up the extra |
| 137 |
space on sdc1 that I had to clear off above basically? |
| 138 |
|
| 139 |
As you can tell, I'm still trying to get a good picture in my head of |
| 140 |
how this works. Thanks to all for helping with the paint brushes. ;-) |
| 141 |
|
| 142 |
Dale |
| 143 |
|
| 144 |
:-) :-) |
| 145 |
|
| 146 |
-- |
| 147 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |
Archives