Nem tudom, hogy embernek lesz-e valaha szüksége rajtam kívül erre, de nekem pár éven belül kellett volna néhányszor, és ahhoz pont kellően ritkán csinálom, hogy mindig újra ki kelljen gugliznom, mert elfelejtem.
Szóval adott az otthoni szerverem, amely esetében inkább a minél nagyobb tárhely volt a lényeg, mint az adatbiztonság, ezért mindenféle RAID-re fittyet hányva az itthon előforduló HDD-ket egy LVM kötetté szervezve csináltam belőlük egy Nagy Hálózati Meghajtót. Mivel ezekre is igaz a mondás miszerint "nincs az a HDD, amit meg ne lehetne tölteni", ezért a Nagy Hálózati Meghajtó egy idő után Nem-Elég-Nagy Hálózati Meghajtóvá degradálódik. Ilyenkor a rászánható pénzmagtól függően veszek egy nagyobb lemezt és kicserélek vele egy kisebbet. Ezt a műveletet foglalnám itt most össze.
Hogy is épül fel az LVM?
Van a Physical Volume (PV / Fizikai Kötet) - ez legtöbbször egy winchester vagy annak partíciója, de RAID-kötet vagy bármi más is lehet, ami egyébként adattárolásra alkalmas szokott lenni.
A PV-k Volume Grouppá (VG / Kötetcsoport) foghatók össze.
A VG-n Logical Volume-okat (LV / Logikai Kötet) hozunk létre, ezek partícióknak feleltethetők meg, fájlrendszert lehet rajtuk létrehozni. A tárolandó adatot Physical Extent-ek (PE / ötletem nincs minek fordítsam) reprezentálják, ezek összessége adja a felhasználható tárhelyet és szükség esetén szabadon pakolászhatók az LV-ken. Utóbbira most szükségünk is lesz.
Maga a művelet nem túl veszélyes, én már párszor csináltam, nem lett tőle semminek baja, de persze az sosem árt, ha van biztonsági másolatod a fontos cuccaidról.
Először is leállítunk minden olyan műveletet, ami használná a lemezt, és le is csatoljuk azt.
[root@Echo-Five lenry]# systemctl stop transmission-daemon
[root@Echo-Five lenry]# systemctl stop plexmediaserver
[root@Echo-Five lenry]# systemctl stop smbd
[root@Echo-Five lenry]# umount /mnt/lvmStorage/
Az lvdisplay, vgdisplay és pvdisplay parancsok az LVM fentebb taglalt rétegeiről adnak információt, nálam az lvdisplay azt mondja, hogy[root@Echo-Five lenry]# lvdisplay
--- Logical volume ---
LV Path /dev/VolGroup00/lvol0
LV Name lvol0
VG Name VolGroup00
LV UUID r9WOs9-n3kc-KWiq-3tud-RwRs-7JJQ-53WRgG
LV Write Access read/write
LV Creation host, time Echo-Five, 2017-02-04 23:15:43 +0100
LV Status available
# open 1
LV Size 7.21 TiB
Current LE 1890830
Segments 11
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
Látható hogy valamivel több, mint 7TB tárhelyet ad jelenleg a kötet.
[root@Echo-Five lenry]# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 50
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 5
Act PV 5
VG Size 7.21 TiB
PE Size 4.00 MiB
Total PE 1890830
Alloc PE / Size 1890830 / 7.21 TiB
Free PE / Size 0 / 0
VG UUID 2w62JR-U3sA-AqTA-mfrc-0Qma-DgrE-tvdPIi
Ebből most számunkra az a lényeges információ, hogy a PE-k az LVM teljes területét lefoglalták, és nincs szabad PE. Ez nem azt jelenti, hogy tele van a kötet, hanem hogy annak teljes területét fel tudjuk használni adattárolásra. Ebből következik, hogy egy lemez cseréjéhez le kell pucolni a rajta lévő PE-ket.
Ehhez összébb húzzuk a partíciót, utána pedig az LV-t is, nyilván legalább a szanálandó lemez méretével, ez nálam most kb 1000GB lesz.
[root@Echo-Five lenry]# e2fsck -f /dev/mapper/VolGroup00-lvol0
[root@Echo-Five lenry]# resize2fs /dev/mapper/VolGroup00-lvol0 6T
Én ext4-et használok, más fájlrendszer esetén ezek a parancsok szükség szerint behelyettesítendők. Ext4 esetén az fsck kötelező elem, lemezellenőrzés nélkül nem enged tovább.
Ha itt minden szupi-szuper volt, akkor jöhet az LV csökkentése, ezt érdemes a partíciónál valamivel nagyobb méretűre hagyni. (Persze akinek van ingere, ki is számolhatja, hogy pont ugyanakkorák legyenek, de nincs jelentősége, ez úgyis csak ideiglenes állapot.)
[root@Echo-Five lenry]# lvresize -L -1T VolGroup00/lvol0
WARNING: Reducing active logical volume to 6.21 TiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce VolGroup00/lvol0? [y/n]: y
Size of logical volume VolGroup00/lvol0 changed from 7.21 TiB (1890830 extents) to 6.21 TiB (1628686 extents).
Logical volume VolGroup00/lvol0 successfully resized.
Ez gond nélkül ráhozza a gyanútlan informatikusra a frászt, de azért nyomjunk y-t.
[root@Echo-Five lenry]# lvdisplay | grep Size
LV Size 6.21 TiB
Összement az LV, és ha most ránézünk a Volume Group állapotára, akkor azt láthatjuk, hogy[root@Echo-Five lenry]# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 51
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 5
Act PV 5
VG Size 7.21 TiB
PE Size 4.00 MiB
Total PE 1890830
Alloc PE / Size 1628686 / 6.21 TiB
Free PE / Size 262144 / 1.00 TiB
VG UUID 2w62JR-U3sA-AqTA-mfrc-0Qma-DgrE-tvdPIi
... lett egy csomó szabad PE.
Juhé, mostmár csak arról kellene gondoskodni, hogy ezek mind azon a lemezen legyenek, amit kivennénk az LVM-ből, az adatot tartalmazó PE-k, meg lehetőleg a gépben maradjanak.
A pvdisplay mutatja meg az egyes lemezeket az LVM-en belül[root@Echo-Five /]# pvdisplay
--- Physical volume ---
PV Name /dev/sdd1
VG Name VolGroup00
PV Size 931.51 GiB / not usable 3.71 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 238466
Free PE 0
Allocated PE 238466
PV UUID J3y5NX-F2JC-bUgW-6BAS-nYxg-Ko2K-BZt8Li
--- Physical volume ---
PV Name /dev/sdf1
VG Name VolGroup00
PV Size 1.36 TiB / not usable <3.37 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 357699
Free PE 0
Allocated PE 357699
PV UUID tDD98D-kPE0-UK1M-Sf0S-Tixu-AtYc-3uWL0n
--- Physical volume ---
PV Name /dev/sdg1
VG Name VolGroup00
PV Size 1.36 TiB / not usable <3.37 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 357699
Free PE 0
Allocated PE 357699
PV UUID MSYnp7-WfCT-wrhN-FLEK-pxSi-sGdO-NeL2J1
--- Physical volume ---
PV Name /dev/sde1
VG Name VolGroup00
PV Size <1.82 TiB / not usable <4.09 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 476931
Free PE 99595
Allocated PE 377336
PV UUID DnQOME-LTT2-iSmQ-nIN0-teQx-eHRU-aphaGQ
--- Physical volume ---
PV Name /dev/sda4
VG Name VolGroup00
PV Size 1.75 TiB / not usable <4.09 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 460035
Free PE 162549
Allocated PE 297486
PV UUID bkjd6K-EXlY-BO9Y-qrLJ-DUWj-Dwyc-epMFs8
Én sdd-t venném ki a rendszerből, de az látszik, hogy az dugig van PE-vel, egy szabad sincs rajta, ezért el kellene róla mozgatni azokat, szerencsére nem ez a művelet lebonyolultabb része:[root@Echo-Five lenry]# pvmove /dev/sdd1
Ha nem is ez a legbonyolultabb, de mindenképp ez tart a legtovább, simán meg lehetne alatta nézni egy filmet, ha nem a szóban forgó gépen tartanám az összes filmemet.
Mivel nem feltétlenül jó dolog, ha ez megszakad, akkor is ajánlom a parancs screen-ben futtatását, ha lokális terminálban dolgozunk.
Miután ez megvan, eltávolítjuk a kötetet a VG-ből:[root@Echo-Five lenry]# vgreduce VolGroup00 /dev/sdd1
Removed "/dev/sdd1" from volume group "VolGroup00"
Majd a lemezről is töröljük a PV-re vonatkozó besorolást, hogy azt máshol felhasználva ne gondolja a rendszer, hogy LVM-be kellene illesztenie.[root@Echo-Five lenry]# pvremove /dev/sdd1
Labels on physical volume "/dev/sdd1" successfully wiped.
Most lehet lemezt cserélni, az új lemez meglepő módon szintén sdd lett.
Az ArchWiki szerint jobb ötlet partíciót megadni PV-ként, mint az egész lemezt, úgyhogy a szívünknek kedves partíció-kezelővel létrehozunk egy Linux LVM (8e) típusú partíciót, és aztán ebből PV-t készítünk.[root@Echo-Five /]# pvcreate /dev/sdd1
Physical volume "/dev/sdd1" successfully created.
Ezt hozzáadjuk a meglévő kötetcsoporthoz[root@Echo-Five /]# vgextend VolGroup00 /dev/sdd1
Volume group "VolGroup00" successfully extended
A vgdisplayben láthatjuk, hogy ott a csomó hely, már csak fel kell használni[root@Echo-Five /]# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 58
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 5
Act PV 5
VG Size 8.12 TiB
PE Size 4.00 MiB
Total PE 2129295
Alloc PE / Size 1628686 / 6.21 TiB
Free PE / Size 500609 / <1.91 TiB
VG UUID 2w62JR-U3sA-AqTA-mfrc-0Qma-DgrE-tvdPIi
Egy jól irányzott paranccsal átméretezzük az LV-t és a fájlrendszert is[root@Echo-Five /]# lvresize -l +100%FREE --resizefs VolGroup00/lvol0
fsck from util-linux 2.33.1
/dev/mapper/VolGroup00-lvol0: The filesystem size (according to the superblock) is 1936209920 blocks
The physical size of the device is 1667774464 blocks
Either the superblock or the partition table is likely to be corrupt!
/dev/mapper/VolGroup00-lvol0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Filesystem check failed.
Napasztmek 
[root@Echo-Five /]# fsck /dev/mapper/VolGroup00-lvol0
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
The filesystem size (according to the superblock) is 1936209920 blocks
The physical size of the device is 1667774464 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes
Na gondolkodjuk: valamiért a fájlrendszer mérete a régi maradt, és most nyilván ki szeretne terjedni egy nem létező részre is... Átméretezni nem enged fsck nélkül, az fsck meg nem hajlandó lefutni az inkonzisztencia miatt.
Mivel kevés igazán lényeges adat van a köteten, ezért léptem egy merészet: mivel az új, nagyobb lemez már benn van, ezért az LV mérete valójában már nagyobb, mint amit éppen a PV mutat, ezért előbb kiterjesztettem az LV-t, aztán kértem a fájlrendszer átméretezését (normál esetben is ennek kellett volna következnie a nagyobb lemez behelyezése után)
[root@Echo-Five /]# lvresize -l +100%FREE /dev/mapper/VolGroup00-lvol0
Size of logical volume VolGroup00/lvol0 changed from 6.21 TiB (1628686 extents) to 8.12 TiB (2129295 extents).
Logical volume VolGroup00/lvol0 successfully resized.
[root@Echo-Five /]# resize2fs -f /dev/mapper/VolGroup00-lvol0
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/VolGroup00-lvol0 to 2180398080 (4k) blocks.
The filesystem on /dev/mapper/VolGroup00-lvol0 is now 2180398080 (4k) blocks long.
Ezek lefutottak gond nélkül, nézzük mit mond az fsck:
[root@Echo-Five /]# e2fsck /dev/mapper/VolGroup00-lvol0
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
e2fsck: Group descriptors look bad... trying backup blocks...
/dev/mapper/VolGroup00-lvol0 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Group 59089's block bitmap at 1936195587 conflicts with some other fs block.
Relocate<y>? yes
No igen, ez várható volt... Egy javíts ki mindent parancs kiadása és pár órával később kiderült, hogy az fsck ekkora javítandó fájlmennyiségnél egyszerűen a jóisten RAM-jából is kifut, ezért ezen a ponton elengedtem az egészet. Igen, én is megtaláltam, hogy az fsck-nak lehet swapot adni, de baszta használni, úgyhogy nem érdekelt a dolog.
Szerencsére mountolható volt továbbra is, így a fontosabbját lementettem, és aztán az egészet ledaráltam és létrehoztam újra, visszamásoltam, most van egy 9TB-s nagy kötetem, 5.9TB szabad hellyel. Végülis megcsináltam, ami a terv volt, de nem egészen úgy, ahogy terveztem. Az nincs meg, hogy pontosan mi ment félre, az mindenképp hiba volt, hogy a pvmove után, a vgreduce előtt nem ellenőriztem, hogy tutira nem maradt-e adat az sdd1 köteten, bár elvileg nem maradt, de az első tippem ez.
Aki megmondja pontosan mit szúrtam el, azt meghívom egy rendes sörre, ha egyszer találkozok vele.
