Resize di partizioni LVM

Mi è capitato di recente, di dover migrare un piccolo server Linux su un server ESXi 4. La memoria ram della versione virtualizzata è stata espansa di 512 MB rendendo necessario una espansione della partizione di swap. Come accade per diverse distribuzioni che utilizzano LVM per gestire il file system (CentOS, Fedora,…) per variare le dimensioni di una partizione (resizing) bisogna tenere in considerazione alcuni fattori critici come ad esempio il rischio di perdere dati importanti presenti sul disco.

L’esempio che segue mostra come ridurre la partizione LVM destinata al sistema operativo al fine di estenderne quella di swap. I comandi elencati però possono essere utilizzati ovunque sia necessario fare il resize di partizioni LVM.

Individuare e gestire le partizioni LVM
Nel caso in cui il sistema operativo sia stato installato come consigliato dalla distribuzione, allora i volumi logici presenti sul disco conterranno l’intera distribuzione ad esclusione della partizione di boot. Questo vuol dire che per accedere al disco per fare le opportune modifiche è necessario accedervi dall’esterno. Per fare questo è sufficiente fare il boot da chiavetta usb o da distribuzione live.

A me piace tanto Fedora, di conseguenza, per questo esempio, prenderò in considerazione il cd live di Fedora, disponibile sul sito:

http://fedoraproject.org/get-fedora

Una volta fatto il boot da cdrom avremo la possibilità di verificare l’esistenza di partizioni LVM sul disco fisso. Basta aprire una finestra terminale ed impartire i seguenti comandi con credenziali di root:

[root@localhost liveuser]# su
[root@localhost liveuser]# pvscan
  PV /dev/sda2   VG VolGroup01   lvm2 [79.88 GB / 0    free]
  Total: 1 [79.88 GB] / in use: 1 [79.88 GB] / in no VG: 0 [0   ]

[root@localhost liveuser]# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup01" using metadata type lvm2

[root@localhost liveuser]# lvscan
  ACTIVE            '/dev/VolGroup01/LogVol00' [78.88 GB] inherit
  ACTIVE            '/dev/VolGroup01/LogVol01' [1.00 GB] inherit

Si tratta di un disco da 80 GB  (sda) con due partizioni fisiche: sda1 per il boot ed sda2 per LVM.
Dai comandi impartiti si evince che il dispositivo /dev/sda2 contiene un gruppo logico (VolGroup01) con due partizioni (LogVol00 per il sistema operativo e LogVol01 per lo swap).

Prima di procedere con il resize delle partizioni logiche bisogna essere certi che non vi siano dati nella parte finale del primo volume (LogVol00) altrimenti questi saranno irrimediabilmente persi. Questa considerazione va fatta dal momento che per aggiungere un numero variabile di byte alla partizione di swap, bisogna prima sottrarli a quella del sistema operativo. Ovvio che se la partizione del SO è piena, il resize non sarà possibile.

Il resize delle partizioni logiche
Poichè LogVol00 è di tipo ext3, possiamo deframmentare l’unità in modo da lasciare libero lo spazio in coda (shrinking):

[root@localhost liveuser]# e2fsck -f /dev/VolGroup01/LogVol00
e2fsck 1.41.9 (22-Aug-2009)
Adding dirhash hint to filesystem.

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/VolGroup01/LogVol00: ***** FILE SYSTEM WAS MODIFIED *****
/dev/VolGroup01/LogVol00: 107628/20676608 files (1.3% non-contiguous), 1409699/20676608 blocks

Fatto questo procediamo con il resize della partizione ext3

[root@localhost liveuser]# resize2fs /dev/VolGroup01/LogVol00 77880M
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/VolGroup01/LogVol00 to 19937280 (4k) blocks.
The filesystem on /dev/VolGroup01/LogVol00 is now 19937280 blocks long.

Con il comando precedente abbiamo tolto alla partizione 1 G definendo le nuove dimensioni (77880M)

Adesso finalmente possiamo contrarre la partizione logica del primo volume ed estendere la seconda:

[root@localhost liveuser]# lvresize /dev/VolGroup01/LogVol00 --size -1G
  WARNING: Reducing active logical volume to 77.88 GB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LogVol00? [y/n]: y
  Reducing logical volume LogVol00 to 77.88 GB
  Logical volume LogVol00 successfully resized

[root@localhost liveuser]# lvresize /dev/VolGroup01/LogVol01 --size +1G
  Extending logical volume LogVol01 to 2.00 GB
  Logical volume LogVol01 successfully resized

In questo caso abbiamo utilizzato valori relativi (-/+1 G)

Per finire, possiamo procedere con la formattazione della nuova partizione di swap

[root@localhost ~]# mkswap /dev/VolGroup01/LogVol01
Setting up swapspace version 1, size = 2147479 kB

Dopo un reboot tutto è pronto.
Alla prossima.

ReadyNas Duo e LVM

Qualche giorno fa è nata la necessità di espandere un ReadyNas Duo della Netgear dotato di disco da 500GB. L’intenzione era quella di sostituire il disco esistente con due dischi da 1TB. Il risultato è stato la perdita di tutti i dati (vedi post).

A questo punto ho deciso di fare a modo mio resettando il NAS non prima di aver fatto un backup del disco esistente da 500gb.

Per fare questo mi sono collegato in remoto al NAS ed ho impartito i comandi:

tar cvpzf /myshare/nas_pre_dsk_upg.tgz –exclude=/shareX –exclude=/shareY –exclude=/proc –exclude=/lost+found –exclude=/c –exclude=/tmp –exclude=/sys –exclude=/home /

Nel comando precendete le cartelle shareX e shareY sono condivisioni di rete.

Come vedremo in seguito questo backup non è strettamente necessario ma io ho sempre l’abitudine di salvare i files che mi servono in caso di necessità. Il comando prececedente serve sostanzialmente a preservare i files del NAS ad esclusione delle condivisioni (che possono essere tranquillamente copiate da un computer remoto). tar è utile perchè sul NAS oggetto di aggiornamento sono presenti diverse add-on per le quali non ho voglia di procedere alla reinstallazione tramite frontview.

Fatto il backup sostituisco il drive da 500GB con due dischi da 1TB e provvedo a resettare il NAS riportandolo alle impostazioni di fabbrica.
Segue la creazione di un nuovo RAID e l’installazione dell’unica add-on necessaria: ToggleSSH disponibile qui.

Sono riuscito a fare il ripristino del backup eseguendo sul NAS i comandi:

cd /
tar xzvf /nas_pre_dsk_upg.tgz

Il restore è andato liscio come l’olio.

Come dicevo prima, il ripristino dei rimanenti files può essere portato a termine mediante l’uso delle condivisioni di rete ma io ho deciso di ripristinare i files usando il disco da 500GB originale tramite porta USB ed un comune convertitore SATA/USB.

Chi volesse impiegare il metodo descritto di seguito ma non ha un convertitore può:

- usare un case esterno;
- clonare il disco di orinine usando dd su un HD esterno di capacità uguale o maggiore di quello sorgente;
- utilizzare una distribuzione live di linux che supporti LVM (ad esempio il disco di ripristino che accompagna fedora) ed un altro computer.

Ho diciso di pubblicare questo metodo perchè potrebbe sorgere la necessità di recuperare i dati da un volume non più utile.

Nel mio caso ad esempio, l’espansione del RAID portato a termine dal ReadyNAS Duo non è andato a buon fine, di conseguenza tutti i dati presenti nel vecchio RAID sono stati cancellati nel nuovo.

Potrebbe inoltre capitare di dover recuperare i dati da un NAS defunto.

I comandi che seguono sono utili anche per chi non possiede un ReadyNas Duo ma vuole recuperare file presenti in partizioni LVM di linux.

Chi volesse cimentarsi nel ripristino tramite altro computer (cioè smontando il disco dal NAS e montandolo su un altro PC dotato di Linux con supporto LVM) avrà una vita più comoda perchè non bisogna considerare alcuni aspetti come ad esempio la duplicazione dei Volume Group (VG).

Riprendendo il filo del discorso, dopo aver resettato il NAS è possibile collegare tramite porta usb il vecchio disco esterno; il NAS provvederà in piena autonomia a montare le partizioni trovate nella directory /USB.

Il comando mount dovrebbe produrre un output del tutto simile al seguente:

mount


/dev/hdc1 on / type ext2 (rw,noatime)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /ramfs type ramfs (rw)
tmpfs on /USB type tmpfs (rw,size=16k)
/dev/c/c on /c type ext2 (rw,noatime,acl,user_xattr,usrquota,grpquota)
/c/home on /home/ftp/homes type bind (rw,bind)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /USB/USB_HDD_1_1 type ext3 (rw,noatime,acl)
/USB/USB_HDD_1_1 on /home/ftp/USB_HDD_1_1 type none (rw,bind)

Viene montata solo la partizione ext3 (USB_HDD_1_1) contenente tutti i files del NAS ad esclusione di quelli presenti nelle condivisioni di rete. Se non avere fatto il backup descritto in precedenza tramite tar, potete tranquillamente copiare i file presenti in /USB/USB_HDD_1_1 avendo l’accortezza di utilizzare il parametro -p (che preserva gli attributi dei files copiati).

Quello che però a noi interessa adesso è il recupero dei dati presenti nel LVM del disco che il NAS non ha montato. Quindi procediamo a verificare la tabella delle partizioni presenti sul disco:

fdisk -l /dev/sda


Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0×00000000


Device Boot Start End Blocks Id System
/dev/sda1 1 255 2048000 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 255 287 256000 82 Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3 287 60800 486064152 5 Extended
/dev/sda5 287 60800 486064151+ 8e Linux LVM

Con fdisk sappiamo che il disco presenta una partizione ext3 (già mondata su USB_HDD_1_1) una partizione di swap (non usata) ed una LVM (che contiene i dati a noi necessari).

Per visualizzare con maggior dettaglio le informazioni legate a LVM è possibile usare il comando pvscan:

pvscan


PV /dev/md2 VG c lvm2 [929.03 GB / 0 free]
Total: 2 [1.36 TB] / in use: 2 [1.36 TB] / in no VG: 0 [0 ]

Non ci sono tracce della partizione /dev/sda5. Questo perchè la scansione delle partizioni LVM da parte del ReadyNAS Duo è stata disabilitata. Basta dare una occhiata al file di configurazione presente in /etc/lvm/lvm.conf per capire che è stato attivato un filtro che evita la scansione di partizioni presenti su porta USB:

filter = [ "a|^/dev/hd[cegikmoq][5-9]$|”, “a|^/dev/hd[cegikmoq]1[0-5]$|”, “a|^/dev/md[2-9]$|”, “r|.*|” ]

Per risolvere il problema suppongo sia sufficiente commentare il filtro ma per essere più precisi è sufficiente apportare le dovute modifiche sostituendo la riga precedente con questa:

filter = [ "a|^/dev/sd[abcegikmoq][5-9]$|”,”a|^/dev/hd[cegikmoq][5-9]$|”, “a|^/dev/hd[cegikmoq]1[0-5]$|”, “a|^/dev/md[2-9]$|”, “r|.*|” ]

Dopo aver modificato il file, l’output del comando pvscan è diverso:

pvscan

PV /dev/sda5 VG c lvm2 [463.53 GB / 0 free]
PV /dev/md2 VG c lvm2 [929.03 GB / 0 free]
Total: 2 [1.36 TB] / in use: 2 [1.36 TB] / in no VG: 0 [0 ]

Adesso siamo in grado di vedere due VG invece che uno ma c’è un problema: entrambi hanno lo stesso nome: “c“. Questo vuol dire che non è possibile montare il volume senza mettere mano ai VG.

Per avere un maggior dettaglio sui VG presenti è possibile fare un controllo con vgdisplay:

vgdisplay

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
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 1
Act PV 1
VG Size 463.53 GB
PE Size 32.00 MB
Total PE 14833
Alloc PE / Size 14833 / 463.53 GB
Free PE / Size 0 / 0
VG UUID q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 929.03 GB
PE Size 32.00 MB
Total PE 29729
Alloc PE / Size 29729 / 929.03 GB
Free PE / Size 0 / 0
VG UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB

Montare il volume presente in /dev/sda5 comporta il riconoscimento del relativo VG. Per poter maneggiare il VG è necessario rinominarlo e per rinominarlo è necessario portarlo offline.

Il primo problema è quello di portare offline il VG perchè in caso di duplicazione dei nomi LVM darà la priorità agli array creati sul NAS e questo vanifica il tentativo. Ad esempio, eseguendo il comando vgchange il risultato sarà simile al seguente:

vgchange -a n c


WARNING: Duplicate VG name c: fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB (created here) takes precedence over q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv
Can’t deactivate volume group “c” with 1 open logical volume(s)
Can’t deactivate volume group “c” with 1 open logical volume(s)

Il comando precente tenta di portare offline il VG c ma poichè la precendeza viene data al volume con UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB il comando fallisce perchè attualmente il volume è usato dal sistema operativo (vedi comando mount eseguito in precedenza).

La cosa più veloce da fare è quella di smontare la partizione /c in modo da poter portare temporaneamente offline entrambi i VG:

/etc/init.d/frontview stop
/etc/init.d/samba stop
/etc/init.d/nis stop
/etc/init.d/proftpd stop

I comandi riportati in alto servono a fermare temporaneamente quei servizi che potrebbero utilizzare la partizione /c inibendo di fatto la possibilità di smondare la partizione /dev/c/c.

Adesso proseguiamo con lo smontaggio:

umount /c/home
umount /dev/c/c

Se lo smontaggio non dovesse funzionare è possibile verificare quali processi fanno uso della partizione tramite il comando fuser:

fuser -m /dev/c/c

Per ogni processo individuato da fuser è necessario procedere con:

kill -9 pid

dove pid è il numero segnalato da fuser. Prima di procedere accertarsi di non escludere un programma essenziale (come ad esempio la shell bash alla quale siamo collegati per impartire i comandi). A volte l’unità non viene smontata perchè il prompt attuale è in “/c” (o magari nella cartella home dell’utente anche essa montata sotto “/c”).

Fatto questo possiamo finalmente portare offile tutti i VG:

vgchange -a n

Se tutto è andato liscio è possibile ora rinominare il VG del vecchio disco specificando il corretto uuid che contraddistingue il gruppo:

vgrename q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv d

Anche questo comando non dovrebbe creare problemi e con vgchange possiamo riportare i VG online:

vgchange -a y

Prima di riavviare il NAS facciamo una verifica finale sul lavoro con vgdisplay:

vgdisplay


— Volume group —
VG Name d
System ID
Format lvm2
Metadata Areas 1
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 1
Act PV 1
VG Size 463.53 GB
PE Size 32.00 MB
Total PE 14833
Alloc PE / Size 14833 / 463.53 GB
Free PE / Size 0 / 0
VG UUID q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 929.03 GB
PE Size 32.00 MB
Total PE 29729
Alloc PE / Size 29729 / 929.03 GB
Free PE / Size 0 / 0
VG UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB

Finalmente i gruppi hanno nomi differenti ed la loro gestione diventa possibile.

Dopo aver riavviato il NAS è possibile finalmente montare la partizione:

pvscan
mount /dev/d/c /USB/USB_HDD_1_1/c

Per ripristinare i files possiamo procedere con:

cd /USB/USB_HDD_1_1/c
cp -Rpv . /c/

Spero che questa piccola guida possa tornare utile a chi ha problemi di recupero dati da partizioni LVM. A volte le cose non sono complicate come sembrano.

Alla prossima.