lvm — Cyberdyne Systems

Cose molto notevoli su LVM

Mon, 25 May 2026 06:08:02 +0000

Oltre che alla grande flessibilità nella gestione dei volumi, LVM attraverso device mapper, aggiunge tutta una serie di ulteriori capacità che rendono questa tecnologia estremamente versatile.

La possibilità di disporre di meccanismi per la gestione di snapshot, cache pool. thin provisioning e raid, rendono LVM qualcosa di più di un gestore di volumi.

1. Snapshot
- 1.1. Attenzione: Dimensione della snapshot
- 1.2. Esempio
2. Thin Pool
3. Thin Pool e snapshot
4. Cache Pool
5. LVM Stripe
6. LVM Mirror
7. LVM Raid

1. Snapshot

Le snapshot LVM usano la tecnica del Copy-on-Write (CoW) allo scopo di ridurre la duplicazione.

La snapshot dovrà essre la fotografia del volume prima all'origine.

Ad ogni modifica / cancellazione, il file originale verrà portato sulla snapshot prima dell'operazione. Sul volume originale verranno scritti tutti i dati nuovi e quelli modificati.

Per il ripristino, si effettua quello che si chiama merge, dove i dati vecchi vengono ripristinati dalla snapshot e quelli nuovi cancellati dal volume.

Per il consolidamento delle modifiche, basterò rimuovere la snapshot,

1.1. Attenzione: Dimensione della snapshot

Se la snapshot ha la stessa dimensione del volume logico non ci sono problemi.

Se è più piccola, occorre prestare attenzione a che la quantità dei dati modificati sul volume logico non superino la dimensione della snapshot.

In questo caso infatti la snapshot risulterà inutilizzabile e non potrà più essere usata per il ripristino ma potrà essree solo rimossa.

1.2. Esempio

Supponiamo di avere un gruppo di volumi, my_vg, composto da 3 volumi logici:

lv_root (30 GiB)
lv_home (200 GiB)
lv_dati (500 GiB)

e di voler creare una snapshot precauzionale sulla root (supponendo di avere spazio a sufficienza altrimenti dovrò fare bene i miei conti per non riempire oltremisura la snapshot rendendola inservibile).

Creazione snapshot

lvcreate -s -L 30G -n  lv_root_snap my_vg/snap

Ripristino

umount /dev/my_vg/lv_root
lvconvert --merge my_vg/snap

Consolidamento

lvremove snap

2. Thin Pool

Il thin provisioning di LVM è l'alternativa dinamica alla classica gestione di volumi, thick, che prevede l'assegnazione statica delle dimensioni dei volumi.

Se è vero che il thick provisioning risulta comunque abbastastanza agevole per via della flessibilità intrinseca dei volumi in caso di riduzione o aumento della superficie allocabile, il thin provisioning può aumentare i vantaggi derivanti da LVM in alcuni scenari.

Il thin provisioning si basa sul principio che lo spazio assegnato ai volumi non viene usato mai completamente e mai tutto in una volta.

Ecco perché un'allocazione dinamica ci permetterebbe di definire volumi che si riempiono solo man mano che lo spazio viene occupato.

Se si opta per un thin provisioning sarebbe opportuno non usare tutto il gruppo di volumi ma lasciarne un 20% in previsione di future espansioni.

Con i thin pool non solo abbiamo la stessa flessibilità della gestione thick, ma possiamo lavorare anche in over provisioning ossia creare pool di volumi la cui somma potenziale sia superiore allo spazio realmente allocabile.

Es. Supponiamo avere un device da 100 GiB, /dev/sdb, su cui definisco un volume group e creare un thin pool di 50 GiB. Su questo thin pool creeremo 3 volumi “virtuali” da 20, 30 e 20 GiB.

# creazione volume group di 100 GiB
vgcreate vg_lab /dev/sdb

# creazione thin pool da 50 GiB
lvcreate -L 50G --thinpool vg_lab/lv_tp

# creazione dei 3 volumi virtuali in "over provisioning" 
lvcreate -V 20G --thin -n vol1_virt --thinpool vg_lab/lv_tp
lvcreate -V 30G --thin -n vol2_virt --thinpool vg_lab/lv_tp
lvcreate -V 20G --thin -n vol3_virt --thinpool vg_lab/lv_tp

Una volta creati i volumi possono essere formattati e montati come di consueto.

Lo spazio effettivamente occupato è quasi nullo, il sistema solleverà solo un warning per avvertirci che i volumi virtuali rischiano di saturare lo spazio disponibile.

Ecco perché bisogna prestare attenzione al raggiungimento della soglia critica. Bisognerà estendere subito il thin pool ed i volumi virtuali nel modo consueto.

⚠️⚠️⚠️ ATTENZIONE ⚠️⚠️⚠️ L'estensione di un volume virtuale non differisce molto da quello di un volume “classico”. Se lo spazio per le fette si sta esaurendo, si estendono nell'ordine:

il gruppo di volumi (se necessario)
il thin pool (se nel volume group c'è spazio a sufficienza)
i volumi virtuali
i filesystem

Se non siamo con l'acqua alla gola, i punti 3 e 4 sono sufficienti. L'estensione del volume virtuale è più rapida di quella classica perché non viene allocato spazio. L'estensione di un volume logico classico corrisponde all'estensione del thin pool.

Nel caso di riduzione, la situazione cambia parecchio perché la riduzione di un volume virtuale non fa guadagnare spazio allocabile visto che l'ampiezza del volume è solo teorica, ciò avviene solo con fstrim. Inoltre accorciando il volume virtuale al di sotto dei dati effettivamente scritti, si rischia di corrompere l'intero filesystem. Consiglio spassionato: ESTENDI SEMPRE E NON RIDURRE MAI!!!

Altra considerazione va fatta anche per i metadati.

A differenza dell'LVM classico dove la creazione di un volume logico necessitava di un extent per i metadati, il thin provisioning di LVM riserva un volume logico per i dati e un volume logico per i metadati.

L'estensione continua di piccole fette, può riempire il volume dei metadati col rischio di corrompere l'intero thin pool e prima che succeda, anche il volume dei metadati può dover essere esteso.

lvextend --poolmetadatasize +1G vg_lab/lv_tp

3. Thin Pool e snapshot

Un altro bel vantaggio della modalità thin pool è quello di facilitare l'uso delle snapshot.

Trattandosi di volumi virtuali, la dimensione della snapshot non ha bisogno di essere dichiarata. La creazione di snapshot è estremamente semplice.

# creazione di una snapshot
lvcreate -s -n lv_snap vg_lab/vol_virt

Come pure sia la creazione di snapshot annidate che il rollback risultano molto più semplici ed efficienti.

# creazione di una snapshot
lvcreate -s -n lv_snap1 vg_lab/vol_virt

# creazione di una snapshot annidata
lvcreate -s -n lv_snap2 vg_lab/lv_snap1

# rollback
umount vol_1
lvconvert --merge vg_lab/lv_snap2
mount -t ext4 -o defaults /dev/vg_lab/vol_virt vol_1

E a proposito di snapshot, occorre fare qualche osservazione.

Una serie di snapshot thin annidate, non è una catena di patch incrementali esposte al filesystem come si potrebbe pensare. In virtù del CoW, la snapshot annidate fotograferanno sempre lo stesso istante: quello del file system all'origine.

Facciamo un esempio:

lvcreate -V 10g -T vgtest/thinpool -n vmroot
mkfs.ext4 /dev/vgtest/vmroot
mount /dev/vgtest/vmroot /mnt/test
echo ORIGINAL > /mnt/test/file.txt
umount test

lvcreate -s -n snap1 vgtest/vmroot

mount /dev/vgtest/vmroot /mnt/test
echo MOD1 > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap2 vgtest/snap1

mount /dev/vgtest/vmroot /mnt/test
echo MOD2 > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap3 vgtest/snap2

mount /dev/vgtest/vmroot /mnt/test
echo MOD3 > /mnt/test/file.txt
umount /mnt/test

In questo esempio creo un volume virtuale, vmroot, e 3 snap annidate.

Monto il volume virtuale.
La prima snapshot, snap1, fotografa il file system del volume virtuale che contiene il file con “ORIGINAL”.
Il volume virtuale viene montato e il file viene modificato.
La seconda snapshot, snap2, fotografa snap1 che a sua volta conteneva il file system del volume virtuale che contiene il file con “ORIGINAL”.
Il volume virtuale viene montato e il file viene modificato.
La terza snapshot, snap3, fotografa snap2 che a sua volta conteneva snap1.. ecc.

Quindi snapshot siffatte non realizzano un versioning del file system come si potrebbe pensare, piuttosto possono essere utili per creare alberi di cloni/read-only, ambienti temporanei derivati da uno stato consistente, ecc.

In sostanza tornano utili quando ho una base da cui faccio derivare n snapshot che condividono i blocchi comune e con CoW minimizzo lo spazio.

Il merge di una qualunque snapshot ricondurrà il file system allo stato originario.

origin
 ├── snap1
 ├── snap2
 ├── snap3

Per lavorare sul delta come immaginiamo, si dovranno montare via via le snapshop, non il volume virtuale, e modificare quelle.

lvcreate -V 10g -T vgtest/thinpool -n vmroot
mkfs.ext4 /dev/vgtest/vmroot
mount /dev/vgtest/vmroot /mnt/test
echo ORIGINAL > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap1 vgtest/vmroot

lvchange -ay -K vgtest/snap1
mount /dev/vgtest/snap1 /mnt/test
echo MOD1 > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap2 vgtest/snap1

lvchange -ay -K vgtest/snap2
mount /dev/vgtest/snap2 /mnt/test
echo MOD2 > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap3 vgtest/snap2

lvchange -ay -K vgtest/snap3
mount /dev/vgtest/snap3 /mnt/test
echo MOD3 > /mnt/test/file.txt
umount /mnt/test

In questo modo si “inverte” la logica del merge che, prima riconduceva il file system allo stato inizale, ora invece consolida le modifiche delle snapshot

origin
 └── snap1
      └── snap2
           └── snap3

Il merge va fatto in ordine se si vogliono acquisire correttamente i delta. Tuttavia questo approccio

è raro
è difficile da gestire
complica i merge
può creare dependency tree intricati

Per questo quasi tutti:

snapshot sempre dell’origin
mai snapshot di snapshot
rollback lineare

4. Cache Pool

Il cache pool di LVM serve a migliorare l'accesso a dispositivi tradizionalmente lenti e lo fa combinando dischi HDD con SSD/NVMe.

In sostanza avremo un gruppo di volumi costituito dai dischi HDD e un altro gruppo di volumi costituito dai dischi SDD/NVMe, la nostra cache.

Il Logical Volume Cache sul disco veloce migliora l'accesso ad uno specifico volume logico del disco lento e prevede il ricorso a tutta una serie di tipi di volumi logici abbastanza variegata:

Origin LV: volume logico orignale costituito dai dischi lenti
Cache pool LV: volume logico composto a sua volta da altri due voumi logici: dati della cache e metadati della cache
- Cache data LV: volume logico contenente i blocchi di dati per il Cache pool LV.
- Cache metadata LV: volume logico contenente i metadatati per il Cache pool LV.
Cache LV: volume logico contenente l'Origin LV e Il Cache pool LV. È il volume realemente utilizzabile
Spare metadata LV: volume logico correlato ad una funzione di recovery data failure

Quando si crea una cache ho due possibilità a seconda che si voglia massimizzare velocità o affidabilità:

writethrough: Le operazioni di scrittura vengono inviate sia alla cache SSD che all'Origin HDD. La lettura avviene preferibilmente dalla cache. È la modalità più sicura. Se l'SSD muore, nessun dato va perso ma è meno efficiente in scrittura perché Origin HDD diventa il collo di bottiglia,
writeback: più veloce ma meno sicuro. Le scritture vengono salvate immediatamente sulla cache veloce e sincronizzate sull'HDD in background in un secondo momento. Se si dovesse rompere il disco di cache, c'è il rischio di una perdita di dati.

Il dimensionamento della cache è proporzionale alla dimensione del disco origin. Di solito si aggira in un range del 2-10%

2%: archiviazione sequenziale, file di grandi dimensioni;
5%: standard consigliato. File server generico, utilizzo desktop/workstation;
10%: carichi di lavoro intensivi e casuali come database SQL/NoSQL attivi, nodi di virtualizzazione densi (molte VM), ecc.

Non è necessario prevedere da subito Il disco di cache (se c'è stata la possibilità tanto meglio), ma si può aggiungere in un secondo momento estendendo il gruppo di volumi contenente l'HDD e battezzando l'LV di cache.

Perpariamo il nostro laboratorio in cui abbiamo un HD lento con un unico volume logico a cui applichiamo una cache.

disco lento: 2 GiB
disco veloce: 500 MiB
cache: 5% di 2 GiB (~100 MiB)

# creazione del device fisico per il laboratorio
fallocate -l 2GiB slow_disk.img

# attach del device e creazione del gruppo di volumi
vgcreate vg_lab $(losetup -Pf --show slow_disk.img)

# creazione e formattazione dell'unico volume logico
lvcreate -n lv_origin vg_lab -l 100%FREE
mkfs.ext4 /dev/vg_lab/lv_origin

Ora aggiungiamo il disco che farà da cache estendendo il gruppo di volumi:

# creazione del device fisico di cache per il laboratorio
fallocate -l 500MiB fast_disk.img

# attach del dispositivo e estensione del gruppo di volumi
DEV_FAST=$(losetup -Pf --show fast_disk.img)
vgextend vg_lab "${DEV_FAST}"

Il cache pool lv può essere configurato automaticamente oppure manualente.

4.1. Caso 1: configurazione automatica del cache pool lv

In un unico passaggio, convertiamo il volume logico attuale in un volume logico con cache.

lvcreate \
  --type cache \
  --cachemode writethrough \
  -l 5%FREE \
  -n cache_pool vg_lab/lv_origin "${DEV_FAST}"

Dopo questo comando vedremo che il volume logico lv_origin incapsula il cache pool (lv_origincache_cpool) e il volume logico dei dati (lv_origin_corig).

Il cache pool è composto da due volumi logici per i dati (lv_origincache_cpool_cdata) e i metadati (lv_origincache_cpool_cmeta).

Infine distinguiamo anche il volume logico di metadati spare da utilizzare per un eventuale data recovery failure (lvol0_pmspare).

lvs -a
  LV                           VG        Attr       LSize   Pool                   Origin            Data%  Meta%  Move Log Cpy%Sync Convert
  home                         vg_fedora -wi-ao---- 409,81g                                                           
  root                         vg_fedora -wi-ao----  50,00g                                                           
  swap                         vg_fedora -wi-ao----  16,00g                                                           
  lv_origin                    vg_lab    Cwi-a-C---  <2,00g [lv_origincache_cpool] [lv_origin_corig] 0,00   0,59            0,00
  [lv_origin_corig]            vg_lab    owi-aoC---  <2,00g                                                           
  [lv_origincache_cpool]       vg_lab    Cwi---C---   8,00m                                          0,00   0,59            0,00
  [lv_origincache_cpool_cdata] vg_lab    Cwi-ao----   8,00m                                                           
  [lv_origincache_cpool_cmeta] vg_lab    ewi-ao----   8,00m                                                           
  [lvol0_pmspare]              vg_lab    ewi-------   8,00m

4.2. Caso 2: configurazione manuale del cache pool lv

Se invece vogliamo intervenire su ogni singolo passaggio della creazione del cache pool:

# creazione dei volumi logici meta e dati per il cache pool
lvcreate -n cache_pool_meta -L 10M vg_lab "${DEV_FAST}"
lvcreate -n cache_pool -l 5%FREE vg_lab "${DEV_FAST}"

# creazione del cache pool assemblando meta e data
lvconvert \
  --type cache-pool \
  --cachemode writethrough \
  --poolmetadata vg_lab/cache_pool_meta vg_lab/cache_pool

# conversione del volume logico origin nel nuovo volume logico con cache
lvconvert \
  --type cache \
  --cachepool vg_lab/cache_pool vg_lab/lv_origin

In realtà è meglio lasciare a LVM il compito di dimensionare correttamente il volume per i metadati.

# creazione della cache pool
lvcreate --type cache-pool -l 5%FREE -n cache_cpool vg_lab "${DEV_FAST}"

# conversione del volume logico originale in un volume logico con cache
lvconvert \
  --type cache \
  --cachepool vg_lab/cache_cpool vg_lab/lv_origin

4.3. Switch della modalità

Per cambiare modalità fra writetrough e writeback (se non specificato nella definizione della cache pool, il default è writethrough).

lvchange --cachemode writeback vg_lab/lv_origin

4.4. Rimozione della cache

Se volessi levare il disco di cache e ritornare al volume logico di partenza:

lvconvert --uncache vg_lab/lv_origin
  Logical volume "lv_origincache_cpool" successfully removed.
  Logical volume vg_lab/lv_origin is not cached.
```https://noblogo.org/ebdpsbxxid/edit#publish
e `lvs -a` mostra il volume logico in queste condizioni:
```bash
lvs -a
  LV        VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_origin vg_lab    -wi-a-----  <2,00g

4.5. Monitoraggio

lvs -a -o lv_name,lv_size,cache_mode,data_percent,metadata_percent vg_lab

5. LVM Stripe

Analogo a Raid 0, l'uso diretto di stripe in lvm attraverso il mappatore interno dm-stripe, permette di definire su quali e quanti dischi va frammentata l'informazione da memorizzare allo scopo di aumentare le prestazioni.

Considerazioni:

Il gruppo di volumi deve contenere almeno due dischi fisici.
È preferibile che i dischi fisici abbiano tutti la stessa velocità altrimenti quello più lento diventerà il collo di bottiglia.
È possibile che i < n, dove i è il numero di dischi per lo stripe e n è il numero totale di dischi del gruppo di volumi
È anche possibile specificare i dischi va applicato lo stripe.
La dimensione dello stripe è di 64K come default. Ma per file molto grandi, video o database, la dimensione può essere anche di 128K o 256K

# creazione di un gruppo di volumi con 3 dischi
vgcreate vg_lab /dev/sdb /dev/sdc /dev/sdd

# stripe su due dischi a caso di vg_lab
lvcreate -i 2 -I 64k -L 10G -n lv_stripe vg_lab

# stripe su tutti i dischi di vg_lab
lvcreate -i 3 -I 64k -L 10G -n lv_stripe vg_lab

# stripe sui dischi sdc e sdd con uno stripe size di 128K
lvcreate -i 2 -I 128k -L 10G -n lv_stripe vg_lab /dev/sdc /dev/sdd

Come ogni raid 0, massime prestazioni e sicurezza 0. Se un disco si rompe, addio ai dati.

6. LVM Mirror

Come per lvm stripe analogo a raid 0, il mirror in lvm tramite il mappatore interno dm-mirror, è assimiliabile a raid 1.

Come ogni raid 1 che si rispetti, il chiaro vantaggio di questo approccio è proprio la ridondanza dei dati che, al costo del sacrificio di un disco, permette di correre ai ripari se uno dei dischi si danneggia.

# creazione di un gruppo di volumi con 2 dischi
vgcreate vg_lab /dev/sdb /dev/sdc

# creazione del volume logico "mirror"
lvcreate -m 1 -L 10G -n lv_mirror vg_lab

Il mirror diretto attraverso LVM in realtà è considerato legacy. Si consiglia di usare l'approccio più moderno che prevede di specificare il tipo, raid x, nell'invocazione di lvcreate perché userà il modulo specializzato del kernel per il raid software.

LVM mirror infatti pur essendo funzionalmente equivalente ad un raid 1 non è altrettanto efficace perché si basa su un log di sincronizzazione dove lvm tiene traccia degli elementi allineati.

Tale log deve stare su un altro disco (che diventa un altro punto di vulnerabilità) e quando c'è bisogno di ricostruire l'array in caso di rottura di un disco, l'operazione è molto lenta.

7. LVM Raid

Il raid lvm è un modo per prendere il meglio dei due mondi.

Non è che LVM abbia una sua implementazione del raid. Il raid “tradizionale” si basa sul sottosistema Multiple Devices del kernel e lavora direttamente sui dispositivi a blocchi.

LVM si interfaccia direttamente con il modulo md del kernel per attingere alle funzioni di raid così da offrire, attraverso device mapper, un'interfaccia unica per la gestione dei volumi e del raid.

7.1. Raid 0 (Stripe)

lvcreate --type raid0 -i 2 -I 64k -L 10G -n lv_raid0 vg_lab

A differenza del mirror, non ci sono gli stessi problemi per stripe. Il mappatore nativo di LVM, dm-stripe, fa bene il suo lavoro.

Usare lvmraid in questo caso resta vantaggioso per ragioni di coerenza. L'uso del modulo md rende possibile un'eventuale evoluzione verso livelli superiori (come RAID 1 o RAID 5).

7.2. Raid 1 (Mirroring)

L'alternativa moderna al vecchio lvm mirror che risolve i suoi problemi di efficienza usando il modulo md.

Basandoci sull'esempio di prima:

lvcreate --type raid1 -m 1 -L 10G -n lv_raid1 vg_lab

7.3. Raid 5 (Stripe con parità singola)

Creiamo un volume logico con RAID 5 basato su 4 dischi (stripe su 3 dischi e uno per la parità):

# creazione di un gruppo di volumi con 4 dischi
vgcreate vg_lab /dev/sdb /dev/sdc /dev/sdd /dev/sde

# creazione del volume logico con RAID 5
lvcreate --type raid5 -i 3 -L 10G -n lv_raid5 vg_lab

7.4. Raid 6 (Stripe con parità doppia)

Se vogliamo una parità doppia su 4 dischi (2 stripe e due di parità);

# creazione di un gruppo di volumi con 4 dischi
vgcreate vg_lab /dev/sdb /dev/sdc /dev/sdd /dev/sde

# creazione del volume logico con RAID 5
lvcreate --type raid6 -i 2 -L 10G -n lv_raid6 vg_lab

7.5. Raid 10

E veniamo al RAID 1+0, uno stripe su n array in mirror per combinare l'efficienza dello stripe con la sicurezza del mirror:

# creazione di un gruppo di volumi con 4 dischi
vgcreate vg_lab /dev/sdb /dev/sdc /dev/sdd /dev/sde

# creazione del volume logico con RAID 5
lvcreate --type raid10 -i 2 -m 1 -L 10G -n lv_raid10 vg_lab

7.6. Come monitorare il raid

Metodo rapido:

lvs -o name,vg_name,copy_percent,lv_attr,raid_health_status,devices vg_lab

# Combinandolo con watch posso vedere per es. la percentuale 
# di completamento della copia in caso di sostituzione del disco
watch -n 1 lvs -o name,vg_name,copy_percent,lv_attr,raid_health_status,devices vg_lab

Metodo dettagliato:

lvdisplay vg_lab/lv_raid5

Monitoraggio a basso livello: Balamente, visto che viene usato il modulo md:

cat /proc/mdstat

7.7. Come intervenire in caso di guasto

Con lvs vedremo che lo stato del volume è diventato degraded. Con pvpdisplay possiamo individuare il device danneggiato che comparirà come unknown device o con un sacco di errori I/O .

Dopo aver estratto il disco e messo quello nuovo, supponendo sia /dev/sdc, procediamo con la ricostruzione dell'array:

# inizializzazione nuovo disco
pvcreate /dev/sdc

# aggiunta del nuovo disco al gruppo
vgextend vg_lab /dev/sdc

# array rebuild
lvconvert --repair vg_lab/lv_raid5

# rimozione disco danneggiato dal gruppo di volumi
vgreduce --removemissing vg_lab

#lvm #dm #devicemapper #md #multipledevices #snapshot #thinpool #thinprovisioning #cachepool #raid #lvmraid

Ridimensionare volumi LVM

Mon, 20 Apr 2026 21:13:18 +0000

Supponiamo di avere 3 volumi logici, ad es. vol1, vol2, vol3 e di voler aumentare il secondo a discapito degli altri due.

Un’esigenza analoga, su un filesystem partizionato in 3 parti in maniera canonica, è un mezzo incubo perché il ridimensionamento della partizione centrale prevede un discreto numero di salti mortali per manenere la contiguità e per non rischiare di lasciare buchetti inutilizzabili fra una partizione e l’altra.

1. Cose che è bene ricordare quando si manipolano i volumi logici
2. Scenario 1: Estensione e riduzione di volumi logici
3. Scenario 2: Estensione e riduzione di gruppi di volume
4. Conclusione

Provo a buttare giù due righe su quello che mi verrebbe di fare:

riduco la prima partizione
riduco la terza partizione
sposto la terza partizione fino alla fine del disco
sposto la seconda partizione fino alla fine della prima partizione
estendo la seconda partizione fino alla fine della prima

Tutto questo tenendo presente che l’unità minima allocabile è il blocco (512 bytes) e che l’operazione che mi fa più paura è il move della partizione. parted non ha un comando “move” diretto. La procedura richiede di calcolare i nuovi settori, spostare i dati e aggiornare la tabella delle partizioni.

Senza una GUI come quella di gparted, bisogna farsi letteralmente i conti con carta e penna prima di agire e c’è il rischio, comunque molto alto, di commettere errori che sarebbero disastrosi.

LVM, al confronto, è una boccata d’ossigeno.

LVM dà la possibilità di ridimensionare volumi in maniera più semplice rispetto al partizionamento più tradizionale perché la dimensione della partizione è disaccoppiata da concetti di contiguità e dalla geometria del disco.

Nel caso del partizionamento tradizionale infatti le partizioni sono dei blocchi di settori consecutivi in cui ogni partizione inizia in un settore finisce in un altro.

Con LVM invece l’approccio è radicalmente diverso. La minima unità allocabile è l’extent (default 4 MiB) che serve per mappare un volume fisico in un volume logico.

Se immaginiamo che il volume fisico possa essere spezzettato in altrettanti extents in una sorta di “paniere”, il volume group, il volume logico non è altro che un insieme di questi extents pescati dal volume group (senza alcuna pretesa d’ordinamento) a cui posso:

aggiungere extents prelevandoli dal volume group
levare extents riponendoli nel volume group (o assegnandoli ad altri volumi logici).

Queste proprietà conferiscono una grande flessibilità alle operazioni di riduzione ed estensione dei volumi.

1. Cose che è bene ricordare quando si manipolano i volumi logici.

Partizioni Quando si riduce o aumenta un filesystem, è bene smontare le partizioni e volumi logici.

Ridurre un volume logico Quando si riduce un volume logico, si deve:

fare un check del filesystem
ridurre il filesystem
ridurre il volume logico

Estendere un volume logico Quando si aumenta un volume logico, al contrario, si deve:

estendere il volume logico
estendere il filesystem
fare un check del filesystem

Calcolare lo spazio allocabile Un volume logico è composto da un insieme di extents, blocchi grandi di default 4 MiB, che sono la minima unità allocabile. Un volume logico è quindi sempre corrispondente ad un multiplo di 4 MiB, n extents di cui n-1 allocabili, il rimanente per i metadati. Ad es. un volume logico di 2 GiB è composta da 512 extents di cui 511 allocabili.

La potenza di due Si deve tenere sempre presente che, nella matematica del calcolo dello spazio, si considerano le potenze di 2. Non di 10. Quindi un GiB equivale a 1024 MiB, non a 1000. Di conseguenza, se dividessi un GiB in due parti uguali avrei 2 blocchi da 512 MiB non da 500.

Estensione e riduzione Nelle istruzioni di estensione (lvextend) e riduzione (lvreduce) possiamo scegliere ciò che va specificato fra 4 modalità:

il numero totale di extents
il delta in aggiunta o in diminuzione degli extents (a seconde che l’operazione sia rispettivamente di estensione o di riduzione)
la dimensione totale espressa in KiB-MiB-GiB-TiB
come prima, il delta in aggiunta o in diminuzione della dimensione espresso in KiB-MiB-GiB-TiB

2. Scenario 1: Estensione e riduzione di volumi logici

Supponiamo di avere un disco da 2 GiB (2048 MiB) diviso in 3 volumi logici da 550 MiB, 350 MiB e 1148 MiB di e di volerne ridurre due per ampliare il terzo.

Vogliamo ridurre il primo di 150 MiB, il terzo di 330 MiB e aumentare corrispondentemente il secondo volume di 480 MiB.

Prepariamo il laboratorio col solito file appiccicato ad un loop device. Su quello definirò il volume group, il mio “paniere” di extents.

# creazione device
fallocate -l 2GiB disk_1.img

# creazione device e volum group
vgcreate vg_lab $(losetup -Pf --show disk_1.img)

# creazione volumi logici
lvcreate -n lv_lab_1 vg_lab -L 550M
lvcreate -n lv_lab_2 vg_lab -L 350M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

# formattazione volumi logici
mkfs.ext4 /dev/vg_lab/lv_lab_1
mkfs.ext4 /dev/vg_lab/lv_lab_2
mkfs.ext4 /dev/vg_lab/lv_lab_3

# mount dei volumi
mkdir vol_1 vol_2 vol_3
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_1 vol_1
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_2 vol_2
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_3 vol_3

2.1. Step 0: curiosità

Prima di cominciare esaminiamo un po’ di dati, ad es. di quanti extents sono composti i nostri oggetti.

pvdisplay /dev/loop9
  --- Physical volume ---
  PV Name               /dev/loop9
  VG Name               vg_lab
  PV Size               2,00 GiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              511
  Free PE               0
  Allocated PE          511
  PV UUID               YmLOru-bIdL-iqGb-vJfI-RsTk-yhv7-vSJhkX

pvdisplay mi dà informazioni sul disco fisico che andrò ad aggiungere nel volume group. Fra queste:

PV Name: il nome del device, /dev/loop9
VG Name: è il nome del gruppo di volume, vg_lab, visibile solo perché abbiamo creato il gruppo di volume direttamente sul dispositivo invece che passare prima da pvcreate.
PV Size: 2 GiB, la dimensione del nostro “disco”
PE Size: dove PE sta Physical Extent, è di 4 MiB
Total PE sono i PE totali e sono 511, come previsto.

vgdisplay vg_lab
  --- Volume group ---
  VG Name               vg_lab
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <2,00 GiB
  PE Size               4,00 MiB
  Total PE              511
  Alloc PE / Size       0 / 0
  Free  PE / Size       511 / <2,00 GiB
  VG UUID               6D89ck-c2Ni-XlMN-5Was-rh5j-vi2t-5juCXt

vgdisplay mi dà informazioni sul gruppo di volumi. Fra queste, disitnguiamo

VG Name: il nome del volume group, già visto in pvdisplay, vg_lab
VG Size: la dimensione del volume group, minore di 2 GiB perché ci sono i metadati da considerari
PE Size: la dimensione di un extent, 4 MiB
Total PE / Size: Il numero totale di extent allocabili, che conferma VG Size, pari a 511 invece che 512.
Alloc PE: il numero totale di extent allocati, momento della creazione del volume group è 0
Free PE / Size: il numero totale di extent liberi, prima della creazione dei volumi logici è 511

Cosa succede quando creerò i volumi logici? Che cambia il numero di PE liberi e allocati. Siccome userò tutti gli extent disponibili, i valori per Alloc PE e Free PE si invertiranno rispetto a prima.

Infatti dopo la creazione dei volumi logici, vgdisplay mi dirà:

vgdisplay vg_lab
  --- Volume group ---
  VG Name               vg_lab
  ...
  Alloc PE / Size       511 / <2,00 GiB
  Free  PE / Size       0 / 0
  ...

511 extents allocati come confermato dai dati desumibili dei 3 volumi logici

lvdisplay vg_lab
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_1
  LV Name                lv_lab_1
  VG Name                vg_lab
...
  LV Size                552,00 MiB
  Current LE             138
...
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_2
  LV Name                lv_lab_2
  VG Name                vg_lab
...
  LV Size                352,00 MiB
  Current LE             88
...
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_3
  LV Name                lv_lab_2
  VG Name                vg_lab
...
  LV Size                1,11 GiB
  Current LE             285
...

Per il primo, il secondo e il terzo volume logico abbiamo rispettivamente:

138, 88, 285 extents corrispondenti a
552 MiB, 352 MiB e 1140 MiB (1,11 GiB)
per un totale di 2044 MiB, al netto dei metadati.

Possiamo notare subito che le dimensioni non corrispondono a quanto indicato in lvcreate.

lvcreate -n lv_lab_1 vg_lab -L 550M
lvcreate -n lv_lab_2 vg_lab -L 350M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

Questo succede perché vengono sempre approssimate all’extent più vicino. Ecco perché il primo e il secondo volume sono diventati di 552 (138 extents) e 352 MiB (88 extents).

Sempre ricordando la particolarità dei multipli di 4 MiB legati a LVM, anche la riduzione di 150 MiB e di 330 MiB dei due volumi saranno approssimate sempre all’extent più vicino (152 MiB=38 extents e 332=83 extents). Questo dettaglio si rivelerà fondamentale quando dovremo ridimensionare il filesystem.

Con questa rinnovata consapevolezza cominciamo a ridimensionare.

2.2. Step 1: Smontare i dischi

umount /dev/vg_lab/lv_lab_1
umount /dev/vg_lab/lv_lab_2
umount /dev/vg_lab/lv_lab_3

2.3. Step 2: Riduzione del filesystem

Se dovessi ridimensionare solo il filesystem, sarebbe sufficiente considerare dimensioni che siano potenze di 2 e non di 10.

Ma sapendo che sotto c’è un LVM, sappiamo che per mantenere l’allineamento fra filesystem e volumi logici, oltre che potenze di due le dimensioni devono essere anche multipli di 4MiB.

Ecco perché anche nel resize reale del filesystem non dovrò levare 150 MiB e 330 MiB ma 148 MiB (37 PE) e 328 (82 PE) (è buona norma approssimare per difetto all’extent più vicino per maggior prudenza) per un totale effettivo di 476 MiB (119 PE)

Il filesystem del primo volume sarà dunque di 552 MiB – 148 MiB = 404 MiB. Il filesystem del terzo volume sarà di 1140 MiB – 328 MiB = 812 MiB.

# check dei filesystem
e2fsck -f /dev/vg_lab/lv_lab_1
e2fsck -f /dev/vg_lab/lv_lab_2
e2fsck -f /dev/vg_lab/lv_lab_3

# Riduco il primo filesystem di 148 MiB
resize2fs /dev/vg_lab/lv_lab_1 404M

# Riduco il terzo filesystem di 328 MiB
resize2fs /dev/vg_lab/lv_lab_3 812M

2.4. Step 3: Ridimensionare i volumi logici

La riduzione del volume logico può essere fatta in 4 modi come sappiamo, ad es. sul primo volume:

# il numero totale di extents, 138 PE - 37 PE = 101 PE
lvreduce -l 101 /dev/vg_lab/lv_lab_1 #oppure

# il numero di exrtents da sottrarre, 38 PE
lvreduce -l -37 /dev/vg_lab/lv_lab_1 #oppure

# la dimensione totale da ottenere, 404 MiB
lvreduce -L 404M /dev/vg_lab/lv_lab_1 #oppure

# il numero di MiB da sottrarre, 148 MiB
lvreduce -L -148M /dev/vg_lab/lv_lab_1 #oppure

Per maggior chiarezza userò il size assoluto in modo da farlo corrispondere a resize2fs

# Riduco il primo volume logico di 148 Mib
lvreduce -L 404M /dev/vg_lab/lv_lab_1

# Riduco il terzo volume logico di 328 Mib
lvreduce -L 812M /dev/vg_lab/lv_lab_3

Verifichiamo quanti siano i PE residui

vgdisplay vg_lab | grep "Free  PE"
 Free  PE / Size       119 / 476,00 MiB

119 extents, come previsto.

2.5. Step 4: Estendere il volume logico

Dopo aver ridotto il primo e il terzo volume, non ci rimane che estendere il secondo in base alla scaletta indicata prima:

si estende il secondo volume logico
si estende il filesystem
si esegue il check fnale del filesystem

L’estensione del volume, come ormai ben sappiamo, non sarà di 480 MiB ma di 476 MiB (37 PE + 82 PE = 119 PE) per via degli arrotondamenti effettuati nella riduzione degli altri volumi logici.

# specifico gli extent che so essere residui
lvextend -l +119 /dev/vg_lab/lv_lab_2
# o, equivalentemente
# lvextend -L +476M /dev/vg_lab/lv_lab_2

# estendo il filesystem
resize2fs /dev/vg_lab/lv_lab_2 828M

# check filesystem
e2fsck -f /dev/vg_lab/lv_lab_2

2.6. Step 5: Bonus

Come premio per essere arrivato in fondo, posso rivelare come fare in un colpo solo tutte le operazioni descritte sopra.

È vero che c'è poco da considerare, giusto tenere a mente che su LVM ogni oggetto è multiplo di 4 MiB e che bisogna ridimensionare filesystem e volumi logici in ugual modo per non generare pericolose anomalie, ma tutte le operazioni che ho descritto nei passi 2-4 possono essere fatte con un unico comando che provvederà ad eseguire nell'ordine corretto e con le giuste approssimazioni:

il check del filesystem
il ridimensionamento del filesystem
il ridimensionamento dei volumi logici

Dunque, tutto il pippone atomico precedente può essere condensato in un unico, solido comando:

# Riduce il primo volume logico e il filesystem
lvreduce -r -L -150M /dev/vg_lab/lv_lab_1

# Riduce il terzo volume logico e il filesystem
lvreduce -r -L -330M /dev/vg_lab/lv_lab_3

# Estende il secondo volume logico e il filesystem
lvextend -r -l +119 /dev/vg_lab/lv_lab_2

Ora spieghiamo il perché soprattutto dell'extend, che è interessante.

Diciamo che è tutto molto guidato e le eventuali correzioni da apportare, senza spaccarsi troppo il cervello, sono suggerite con estrema chiarezza, basta leggere.

lvreduce -r -L -150M /dev/vg_lab/lv_lab_1
 Rounding size to boundary between physical extents: 148.00 MiB.
  File system ext4 found on vg_lab/lv_lab_1.
  File system size (552.00 MiB) is larger than the requested size (404.00 MiB).
  File system reduce is required using resize2fs.
...
  Size of logical volume vg_lab/lv_lab_1 changed from 552.00 MiB (138 extents) to 404.00 MiB (101 extents).
  Logical volume vg_lab/lv_lab_1 successfully resized.

Ci dice innanzitutto che:

c'è stato un arrotondamento a 148 MiB (37 extents);
il filesystem è più grande del volume richiesto pertanto va subito ridimensionato;
infine si ridimensiona il volume logico da 552 MiB (138 extents) a 404 MiB (101 extents).

Anche il secondo lvreduce ha un risultato analogo

lvreduce -r -L -330M /dev/vg_lab/lv_lab_3
  Rounding size to boundary between physical extents: 328.00 MiB.
  File system ext4 found on vg_lab/lv_lab_3.
  File system size (1.11 GiB) is larger than the requested size (812.00 MiB).
  File system reduce is required using resize2fs.
...
  Size of logical volume vg_lab/lv_lab_3 changed from 1.11 GiB (285 extents) to 812.00 MiB (203 extents).
  Logical volume vg_lab/lv_lab_3 successfully resized.

anche qui abbiamo un arrotondamento a 328 MiB (82 extents);
il filesystem è più grande del volume richiesto pertanto va subito ridimensionato;
infine si ridimensiona il volume logico da 1140 MiB (285 extents) a 812 MiB (203 extents).

È facilissimo desumere che la massima dimensione dell'estensione sia 148 MiB + 328 MiB = 476 MiB (119 extents), basta fare una somma.

Ma supponiamo di essere particolarmente distratti e proviamo ad estendere considerando le quantità iniziali: 150 MiB + 330 MiB = 480 MiB

lvextend -r -L +480M /dev/vg_lab/lv_lab_2
  File system ext4 found on vg_lab/lv_lab_2.
  File system fsck will be run before extend.
  Insufficient free space: 120 extents needed, but only 119 available

Nonostante la mia distrazione, come si può vedere, non si producono danni perché l'ouput è categorico: “non faccio nulla. Se vuoi, puoi aumentare al max di 476 MiB (119 extents)”. Non ci sono danni e anzi c'è pure il suggerimento risolutivo.

Ed ecco spiegato il mio extend di prima.

3. Scenario 2: Estensione e riduzione di gruppi di volume

Esaminiamo le possibilità di aggiungere o rimuovere dispositivi ad un volume group esistente.

Ricreiamo il laboratorio partendo da 3 dischi, poi aggiungeremo due nuovi dischi e ne rimuoveremo altrettanti, il tutto senza intaccare l'integrità dei dati.

# creazione di 5 device
for i in {1..5}: do fallocate -l 1GiB disk_${i}.img; done

# creazione del gruppo di volumi con 3 device
vgcreate vg_lab \
  $(losetup -Pf --show disk_1.img) \
  $(losetup -Pf --show disk_2.img) \
  $(losetup -Pf --show disk_3.img)

# crezione di 3 volumi logici
lvcreate -n lv_lab_1 vg_lab -l 300
lvcreate -n lv_lab_2 vg_lab -l 250
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

# formattazione dei 3 dispositivi
mkfs.ext4 /dev/vg_lab/lv_lab_1
mkfs.ext4 /dev/vg_lab/lv_lab_2
mkfs.ext4 /dev/vg_lab/lv_lab_3

Ecco come sono distribuiti i volumi logici all'interno dei dischi fisici

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm

Il gruppo di volumi è composto da 3 volumi fisici tutti attivi

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                3
  Act PV                3

Andiamo ad estendere il nostro gurppo di volumi con altri due device

vgextend vg_lab $(losetup -Pf --show disk_4.img) $(losetup -Pf --show disk_5.img)

I nuovi dischi sono visibili in fondo, come si può vedere anche da vgdisplay che mostra i 5 dischi tutti attivi.

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvmchan
  loop12             LVM2_member     1G      loop
  loop13             LVM2_member     1G      loop

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                5
  Act PV                5

Potremo usare i nuovi dischi per estendere i volumi logici esistenti ma li impiegheremo invece per rimpiazzare i primi due dischi.

pvmove distribuisce tutti gli extents del disco fra tutti i volumi fisici che hanno spazio a sufficienza. Se non dovesse essercene, restituirà un messaggio d'errore.

pvmove /dev/loop9
  /dev/loop9: Moved: 3,14%
  /dev/loop9: Moved: 100,00%

Alla fine dell'operazione il disco s'è liberato di tutti i suoi extents e può essere rimosso

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop12             LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop13             LVM2_member     1G      loop

Prima si estrae il volume fisico dal gruppo di volumi e poi si rimuove il volume fisico e così può essere scollegato.

vgreduce vg_lab /dev/loop9
pvremove /dev/loop9

Verifichiamo che il volume fisico non sia più presente.

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                4
  Act PV                4

Procediamo allo stesso modo col secondo disco.

pvmove /dev/loop10
  /dev/loop10: Moved: 9,80%
  /dev/loop10: Moved: 17,65%
  /dev/loop10: Moved: 100,00%

vgreduce vg_lab /dev/loop10
  Removed "/dev/loop10" from volume group "vg_lab"

pvremove /dev/loop10
  Labels on physical volume "/dev/loop10" successfully wiped.

In conclusione possiamo vedere il gruppo di volumi con solo 3 dischi, gli altri due completamente disimpegnati col gruppo di volumi ricostituitosi attorno ai 3 dischi rimanenti. E tutto spostando semplicemente gli extents dove c'era disponibilità in maniera totalmente trasparente per il filesystem.

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                3
  Act PV                3


lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9                              1G      loop
  loop10                             1G      loop
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop12             LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop13             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm

4. Conclusione

Ho solo sfiorato la complessità e le capacità offerte da LVM.

L'estensione e la riduzione di volumi logici e di gruppi di volumi sono scenari di base. Tuttavia sono sufficienti per mostrare come sia semplice, con i volumi logici, compiere operazioni che con un filesystem partizionato in maniera classica sarebbero complicatissime.

#lvm #volumegroup #logicalvolume #filesystem #devicemapper

Device Mapper: LUKS + LVM

Mon, 23 Feb 2026 10:58:17 +0000

(segue da “Cenni sulla creazione di pool di storage con LVM“) ...anche se è la base per una serie di sviluppi interessanti.

Come ormai sappiamo, device mapper è il framework del kernel Linux col quale mappare dispositivi a blocchi fisici su dispositivi a blocchi logici, che costituisce la base per fornire funzionalità ulteriori quali:

volumi logici
raid
cifratura (Full Disk Encryption)
snapshot di volumi

Scenario 1

È molto comune per es. cifrare l'intero disco e “affettarlo” con volumi logici in base alle proprie esigenze di partizionamento .

Il doppio vantaggio è dato da:

offuscamento totale dello schema di partizionamento
estrema versatilità / flessibilità del partizionamento grazie ai volumi logici

Come si agisce?

si cifra il dispositivo fisico
si crea un gruppo di volumi avente come volume fisico il volume cifrato
si creano i volumi logici in base allo schema di partizionamento desiderato.

Passo 1 – Inizializzazione

Simulo il mio dispositivo fisico ricorrendo ai loop device.

Il “disco” avrà una grandezza simbolica di 2 GiB, non avrà header detachable. L'algoritmo di hash sarà sha512 e la chiave sarà da 512 bit. Il resto è il default di luks2 (argon2id come pbkdf, per maggiori dettagli vedi cryptsetup --help)

# 1. Preparazione disco "fisico"
fallocate -l 2g cipher_disk.img

# 2. loop device che simula l'attach del dispositivo
DEV=$(losetup -Pf --show cipher_disk.img)

# 3. Inizializzazione cifratura
cryptsetup luksFormat  \
    --type luks2 \
    --hash sha512 \
    --key-size 512 \
    $DEV

Passo 2

Il passo successivo consiste nell'apertura del dispositivo cifrato e nella definizione dello schema di partizionamento in volumi logici

# 1. apertura del disco cifrato
cryptsetup open \
    --type luks2 \
    $DEV cipher_disk

Nell'apertura, device mapper fa la sua prima magia.

Infatti, se osserviamo lo stato dei dispositivi, vedremo una situazione simile:

lsblk
...
loop9                7:9    Kib0     2G  0 loop  
└─cipher_disk      252:3    0     2G  0 crypt 
...

Cio vuol dire che sopra il dispositivo fisico, /dev/loop9in questo caso, device mapper ha “poggiato” cipher_disk (/dev/mapper/cipher_disk).

Questo sarà il nostro volume fisico per definire gruppi di volume e, conseguentemente, i volumi logici.

# 2. creazione gruppo di volumi
vgcreate vg_lab /dev/mapper/cipher_disk

# 3. creazione volumi logici
lvcreate -n lv_lab_1 vg_lab -L 700M
lvcreate -n lv_lab_2 vg_lab -L 600M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

La situazione dei dispositivi è ora questa:

lsblk
...
loop9                7:9    0     2G  0 loop  
└─cipher_disk      252:3    0     2G  0 crypt
  ├─vg_lab-lv_lab_1 252:4    0   700M  0 lvm
  ├─vg_lab-lv_lab_2 252:5    0   600M  0 lvm
  └─vg_lab-lv_lab_3 252:6    0   728M  0 lvm
...

Sopra /dev/loop9 c'è cipher_disk (/dev/mapper/cipher_disk) e sopra di esso, i 3 volumi logici

lv_lab_1 (/dev/mapper/vg_lab-lv_lab_1)
lv_lab_2 (/dev/mapper/vg_lab-lv_lab_2)
lv_lab_3 (/dev/mapper/vg_lab-lv_lab_3)

Formatto e monto i volumi logici

# 4. formattazione dei 3 volumi logici
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_1
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_2
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_3

# 5. creo e preparo i punti di mmontaggio
mkdir disk_1 disk_2 disk_3
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_1 disk_1
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_2 disk_2
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_3 disk_3
chown $USER disk_1 disk_2 disk_3

# 6. unmount di tutti i dispositivi
umount disk_1 disk_2 disk_3
vgchange -an vg_lab
cryptsetup close cipher_disk
losetup -d $DEV

Passo 3

Infine, per completezza, gli script di mount e unmount del dispositivo. mount

# 1. attach del dispositivo
DEV=$(losetup -Pf --show cipher_disk.img)

# 2. Apre il disco cifrato 
cryptsetup open \
    --type luks2 \
    $DEV cipher_disk

# 3. monta il gruppo di volume
# (opzionale. L'apertura del disco cifrato dovrebbe montare 
# automaticamente il gruppo di volumi)
vgchange -ay vg_lab

# 4. monta i volumi logici
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_1 disk_1
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_2 disk_2
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_3 disk_3

unmount

# 1. smonta i 3 dischi
umount disk_1 disk_2 disk_3

# 2. smonta il gruppo di volumi
vgchange -an vg_lab

# 3. chiude il disco cifrato
cryptsetup close cipher_disk

# 4. "stacca" il dispositivo fisico
losetup -d $DEV

Questo è ciò che si farebbe normalmente quando si vuole il full disk encryption sul proprio pc. Ma con una piccola eccezione.

In realtà ciò che viene cifrata è una partizione quasi completa del disco, perché almeno una piccola partizione, quella contenente il boot, /BOOT, deve essere in chiaro per consentire:

a UEFI di avviare GRUB che conosce le partizioni,
GRUB provvederà all'avvio del kernel,
l'avvio del kernel con initramfs chiederà la password per sbloccare la partizione cifrata.

La cifratura totale (che proprio totale non sarà perché /boot/efi deve rimanere in chiaro) eleva di molto la complessità del setup iniziale.

Affidare a GRUB la gestione della cifratura potrebbe voler dire, oltre alla complessità della configurazione iniziale che dovrà far ricorso a moduli come cryptodisk, che bisognerà rinunciare ad Argon2 perché GRUB ancora non lo supporta pienamente e, a differenza del kernel, non ha sufficiente potenza per farlo lavorare come si deve.

Un buon compromesso potrebbe essere il ricorso ad un dispositivo esterno, es. una pendrive, che contenga tutta la partizione /boot in chiaro, anche l'header del disco cifrato. GRUB dovrà solo sapere dove si trovi il boot, il resto dell'avvio viene affidato come di consueto al kernel.

Scenario 2

Rimanendo nell'ambito dell'esplorazione di device mapper e della cifratura di dispositivi esterni non avviabili, immaginiamo qualcosa di più estremo.

Supponiamo di dover custodire un segreto in qualcosa che non sia un semplice vault cifrato.

Per diminuire il rischio di compromettere un unico vault, decido di dividerlo in varie parti, come gli horcrux ma con 0 malignità. Ogni parte sarà cifrata con una sua chiave che affiderò ad una persona diversa, di mia fiducia. Solo io, titolare ultimo del segreto, avrò accesso ai dati e solo la mia chiave (come l'Anello che li domina tutti) aprirà il vault.

Supponiamo di avere 3 dispositivi fisici (che nel laboratoro saranno simulati da loop device come al solito) per altrettanti “custodi”, ognuno dei quali verrà cifrato con la chiave e con dei parametri da consegnare al “custode” specifico.

I 3 dispositivi cifrati costituiranno un gruppo di volumi con un volume logico (dai requisiti posti non c'è necessità di sfruttare la flessibilità di partizionamento dei volumi logici) che verrà cifrato con la mia chiave master.

Ogni dispositivo, volume logico finale compreso, prima della cifratura, verrà inizializzato con del rumore casuale. Questo per impedire ad un'analisi forense di risalire ad un qualunque pattern sul dispositivo raw.

Caratteristiche di ogni cifratura:

dispositivi inizializzati con rumore casuale
header detachable
offset custom
key-file
default di argon2id (controlla il tuo default con cryptsetup benchmark)

Quando vorrò aprire il vault, sarà necessario che i 3 “custodi” aprano il loro “pezzo” e solo io potrò ricostruire e decifrare il volume con la mia chiave.

L'inzializzazione con rumore casuale dei dispositivo, tralasciando l'uso di dd su /dev/urandom che sappiamo essere CPU-intensive, può essere fatta ricorrendo:

ad openssl rand, come sappiamo da “Come generare una password o un keyfile sicuri (Trilogia Della Password – 1 di 3“
oppure usando furbescamente cryptsetup, con cui apriamo il dispositivo in modalità plain, senza header, e riempiendolo di zeri (da /dev/zero con dd) che, attraversando il motore di cifratura, verranno scritti sul dispositivo come dati casuali ad alta velocità.

################################
# Emulazione dei device fisici #
################################
fallocate -l 512M cipher_disk_1.img
fallocate -l 512M cipher_disk_2.img
fallocate -l 512M cipher_disk_3.img



###########################
# creazione dei 3 keyfile #
###########################
# keyfile del custode n° 1
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_1.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile del custode n° 2
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_2.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile del custode n° 3
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_3.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile master
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o master.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -



##########################
# cifratura dei 3 device #
##########################
# attach dispositivo
DEV_1=$(losetup -Pf --show cipher_disk_1.img)

# inizializzazione dev_1 con rumore casuale
cryptsetup open --type plain ${DEV_1} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_1.img \
        --offset 32768 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_1}

# attach dispositivo
DEV_2=$(losetup -Pf --show cipher_disk_2.img)

# inizializzazione dev_2 con rumore casuale
cryptsetup open --type plain ${DEV_2} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_2.img \
        --offset 36864 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_2}

# attach dispositivo
DEV_3=$(losetup -Pf --show cipher_disk_3.img)

# inizializzazione dev_3 con rumore casuale
cryptsetup open --type plain ${DEV_3} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_3.img \
        --offset 40960 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_3}



##############################
# Creazione gruppo di volumi #
##############################
# "apro" il volume 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_1.img \
         --key-file - \
         ${DEV_1} cipher_disk_1

# "apro" il volume 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_2.img \
         --key-file - \
         ${DEV_2} cipher_disk_2

# "apro" il volume 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_3.img \
         --key-file - \
         ${DEV_3} cipher_disk_3

# Creo il mio gruppo di volumi con i 3 volumi "fisici":
# 1. /dev/mapper/cipher_disk_1
# 2. /dev/mapper/cipher_disk_2
# 3. /dev/mapper/cipher_disk_3
vgcreate vg_master /dev/mapper/cipher_disk_1  /dev/mapper/cipher_disk_2  /dev/mapper/cipher_disk_3

# creazione dell'unico volume logico
lvcreate -n lv_master vg_master -l 100%FREE



################################
# cifratura e mount del master #
################################
# cifratura dispositivo master
dd if=/dev/urandom of=/dev/mapper/vg_master-lv_master bs=1M count=32 status=progress
gpg -d master.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_master.img \
		--offset 65536 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        /dev/mapper/vg_master-lv_master

# apriamo il dispositivo master
gpg -d master.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_master.img \
         --key-file - \
         /dev/mapper/vg_master-lv_master cipher_disk_master

# e finalmente lo formattiamo
mkfs.ext4 /dev/mapper/cipher_disk_master

# Test: montiamo il disco
mkdir -p /run/media/master/disk_master
chown -R ${USER}:${USER} /run/media/master/disk_master
mount -t auto /dev/mapper/cipher_disk_master /run/media/master/disk_master

# Infine chiudiamo tutto
umount /run/media/master/disk_master
cryptsetup close cipher_disk_master
vgchange -an vg_master
cryptsetup close cipher_disk_1
cryptsetup close cipher_disk_2
cryptsetup close cipher_disk_3
losetup -d ${DEV_1} ${DEV_2} ${DEV_3}

Dopo aver appurato che tutto funzioni, consegno ad ogni “custode” dispositivo, keyfile e header.

Se un attaccante dovesse entrare in possesso di uno o più dispositivi, troverebbe solo un mucchio di dati incomprensibili.

Posto che riuscisse a decifrare il dispositivo, troverebbe un pezzo di un gruppo di volumi, cifrato e inutilizzabile.

Il master a questo punto non dovrà fare altro che aprire e chiudere il vault, dopo aver riunito tutti i pezzi, come segue:

Apertura del vault

# Attach dei dispositivi
DEV_1=$(losetup -Pf --show cipher_disk_1.img)
DEV_2=$(losetup -Pf --show cipher_disk_2.img)
DEV_3=$(losetup -Pf --show cipher_disk_3.img)

# "apro" il volume 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_1.img \
         --key-file - \
         ${DEV_1} cipher_disk_1

# "apro" il volume 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_2.img \
         --key-file - \
         ${DEV_2} cipher_disk_2

# "apro" il volume 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_3.img \
         --key-file - \
         ${DEV_3} cipher_disk_3

# (facoltativo) apre il gruppo di volumi
vgchange -ay vg_master

# "apre" il master volume
gpg -d master.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_master.img \
         --key-file - \
         /dev/mapper/vg_master-lv_master cipher_disk_master

# Monta il volume
mount -t auto /dev/mapper/cipher_disk_master /run/media/master/disk_master

Chiusura del vault

# smonta il volume cifrato
umount /run/media/master/disk_master

# chiusura del vault master
cryptsetup close cipher_disk_master

# chiusura del gruppo di volumi
vgchange -an vg_master

# chiusura dei singoli vault cifrati
cryptsetup close cipher_disk_1
cryptsetup close cipher_disk_2
cryptsetup close cipher_disk_3

# deattach dei dispositivi
losetup -d ${DEV_1} ${DEV_2} ${DEV_3}

#cryptsetup #devicemapper #dmcrypt #gpg #loseup #luks #lvm #loopdevice #storage

Cenni sulla creazione di pool di storage con LVM

Tue, 14 May 2024 16:34:11 +0000

Premessa

Supponiamo di voler aggregare dei dispositivi in un unico storage. Potrebbero essere 3 hd nella propria workstation. O un pool di pendrive.

Ognuno di essi avrà dimensioni differenti e se le usassi singolarmente, quasi certamente la loro dimensione condizionerebbe il loro utilizzo.

Visto che la volta scorsa ho accennato a device mapper, vale la pena spendere due parole sui volumi logici e sulla loro utilità. Il fatto di poter aggregare dispositivi fisici diversi in un unico (o più) volume virtuale che si può affettare a piacimento, è un'innegabile flessibilità. Inoltre, ogni operazione di estensione o riduzione sarà eseguita sui volumi logici che rappresentano l'astrazione dei dispositivi fisici sottostanti.

Si deve tenere conto però che aggregare dispositivi di natura molto differente (ad es. dischi ssd e dischi a rotazione) può comportare un'imprevedibilità non trascurabile in termini di prestazioni.

Tutto ciò avviene attraverso dei tool disponibili nella userland grazie ai quali:

si fa il mapping fra dispositivi fisici e volumi fisici
si aggregano i volumi fisici in gruppi di volumi
si “affettano” i gruppi di volume in volumi logici

Oltre a poter rimuovere/aggiungere/ridimensionare volumi fisici, gruppi di volume e volumi logici.

Prova sul campo

Nel nostro laboratorio supporremo di avere 3 dischi di dimensioni differenti che vogliamo usare come un unico volume da partizionare in base ad una necessità che non sia legata alla dimensione del dispositivo fisico.

Per simulare tutto ciò, farò uso di file associati dinamicamente a dei loop device attraverso losetup

Emulazione – Fase 1 di 2

Si inizia con la creazione di 3 file container di dimensioni differenti che emuleranno i “device fisici”

fallocate -l 800M disco1.img
fallocate -l 500M disco2.img
fallocate -l 300M disco3.img

Emulazione – Fase 2 di 2

I block device, solitamente originati nel momento in cui avviene la connessione fisica all'host, in questo caso saranno ottenuti associando i file container ai loop device con losetup

losetup -Pf --show disco1.img
  /dev/loop12
losetup -Pf --show disco2.img
  /dev/loop13
losetup -Pf --show disco3.img
  /dev/loop14

Tutto ciò che è stato fatto finora, serve solo ai fini dell'emulazione. Con dispositivi fisici si può cominciare direttamente dal passo 1

Passo 1

Prendiamo nota dell'ip dei loop device( 12,13,14 in questo esempio) e cominciamo a creare i physical volume.

pvcreate /dev/loop12
pvcreate /dev/loop13
pvcreate /dev/loop14

Passo 2

Dopo aver mappato i volumi fisici con i dispositivi, si farà l'aggregazione in un unico volume group.

vgcreate vg_lab /dev/loop12 /dev/loop13 /dev/loop14

Passo 3

Infine, la creazione dei logical volume. I volumi logici saranno di 100 MiB, 700 MiB, 788 MiB. Non ne fanno parte i 12 MiB dell'header LVM (4 MiB per ogni disco fisico):

lvcreate -n lv_lab_1 vg_lab -L 100M
lvcreate -n lv_lab_2 vg_lab -L 700M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

Questa definizione va bene per la didattica.

Dilingentemente abbiamo fatto ogni singolo passaggio come bravi scolaretti, ma siccome siamo bravi e c'è un modo più compatto per eseguire alcuni passaggi, vale la pena scoprire quali.

Tralasciando la fase di inizializzazione, mi riferisco ai primi 3 passi, che possono collassare in un unico passaggio perché la creazione di un volume group nel passo 3, noto il dispositivo a blocchi del passo 1, può creare implicitamente i physical volume del passo 2.

In realtà i passi 1 e 2 possono collassare in unico passaggio perché la creazione di un volume group crea contestualmente anche i physical volume.

E quindi, emulazione a parte, sintetizzando:

Passo 1bis (passi 1, 2, 3 e 4):

vgcreate vg_lab /dev/loop12 /dev/loop13 /dev/loop14 

lvcreate -n lv_lab_1 vg_lab -L 100M
lvcreate -n lv_lab_2 vg_lab -L 700M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

Questo è il minimo indispensabile per creare dei volumi logici.

Dopo aver creato i volumi logici, bisognerà utilizzarli.

I volumi logici sono volumi a cui device mapper fa corrispondere dei block device virtuali sui quali si creeranno dei file system con la formattazione (un exfat e due ext4), come avviene con qualunque altro volume fisico attraverso il corrispondente block device, e si creeranno i punti di montaggio.

# creazione punti di mount
mkdir  disco1 disco2 disco3

# formattazione volumi logici
mkfs.exfat -L "Disco 1" /dev/mapper/vg_lab-lv_lab_1 
mkfs.ext4 -L "Disco 2" /dev/mapper/vg_lab-lv_lab_2
mkfs.ext4 -L "Disco 3" /dev/mapper/vg_lab-lv_lab_3

Mount LVM Ogni volta che dovremo usare i volumi logici faremo così:

vgchange -ay vg_lab
mount -t exfat -o defaults /dev/mapper/vg_lab-lv_lab_1 disco1
mount -t ext4 -o defaults /dev/mapper/vg_lab-lv_lab_2 disco2
mount -t ext4 -o defaults /dev/mapper/vg_lab-lv_lab_3 disco3

Umount LVM Per smontarli invece basterà:

umount disco1 disco2 disco3
vgchange -an vg_lab

Tutto quello che s'è visto finora, risponde all'esigenza iniziale: come posso aggregare più volumi in unico volume?

Ma riprendendiamo il passo 1bis, per vedere qualcosa di completamente inutile (all'apparenza) ma non per questo meno interessante.

# Passo 1bis
# Fin qua nulla di nuovo.
vgcreate vg_lab $(losetup -Pf --show disco1.img) $(losetup -Pf --show disco2.img) $(losetup -Pf --show disco3.img) 

lvcreate -n lv_lab_1 vg_lab -L 100M
lvcreate -n lv_lab_2 vg_lab -L 700M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

# Passo 2
vgcreate vg_lab_2 $(losetup -Pf --show /dev/vg_lab/lv_lab_3)
lvcreate -n lv_lab_4 vg_lab_2 -l 100%FREE

La particolarità del passo 2, completamente inutile, ha il solo scopo di mostrare come device mapper mi permetta di stratificare i volumi virtuali attraverso i corrispondenti dispositivi a blocchi virtuali per creare delle vere e proprie matrioske di volumi virtuali.

In questo caso, /dev/mapper/vg_lab-lv_lab_3 diventa un dispositivo a blocchi su un loop device ed è un attimo che quel dispositivo a blocchi diventi a sua volte un gruppo di volumi su cui creare un ulteriore volume logico.

Un discreto nonsense anche se... (to be continued)

#lvm #devicemapper #logicalvolume #volumegroup #loopdevice

Come creare un file container cifrato

Fri, 10 May 2024 21:32:57 +0000

Image by d3images on Freepik

Introduzione a cryptsetup + LUKS

Supponiamo di voler creare una piccola cassaforte digitale come faremmo con Veracrypt. Ma senza Veracrypt.

Ciò sarà possibile grazie a dm-crypt. dm-crypt è un modulo del kernel che usa il framework device mapper per fornire funzionalità trasparenti di crittografia per dispositivi a blocchi usando le crypto api del kernel. L’uso di device mapper consente, tra l’altro, di “poggiare” dm-crypt sopra ogni possibile mapping dei dispositivi e quindi può cifrare partizioni, volumi raid o volumi logici. 1. Introduzione a cryptsetup + LUKS 2. Inizializzazione 2. Apertura 2. Chiusura 1. Come creare il file vault 1. Header detachable e keyfile 1. Partizionare un “volume” cifrato

[EDIT 02/03/2026]: Riscrittura del par. 3 – “Header detachable e keyfile”, alla luce degli approfondimenti fatti con “Device Mapper: Luks + LVM” e la “Trilogia delle password – Vol. 1,2 e 3“

Poi, essendo a tutti gli effetti anche un dispositivo a blocchi (virtuale), può essere utilizzabile a sua volta come volume nel file system, come swap o come disco fisico per lvm.

La configurazione della cifratura avviene di solito (non è l’unico modo ma è lo standard de facto) con l’utility cryptsetup + LUKS

Come avviene di base la cifratura di un dispositivo?

Le operazioni principali di cryptsetup (con estensioni LUKS) sono:

luksFormat: stabilisce le modalità di cifratura (consigliato il default)
luksOpen: (deprecato. Si usa open --type luks2) attiva la cifratura sul device associandolo (grazie a device mapper) ad un dispositivo a blocchi virtuale
luksClose (deprecato. Si usa close --type luks2): disattiva la cifratura

Inizializzazione

attacco il dispositivo fisico, viene creata la entry per /dev/
cifratura del dispositivo a blocchi /dev/ con LUKS (cryptsetup luksFormat)
al di sopra del dispositivo a blocchi fisico, viene creato un dispositivo a blocchi virtuale, che troverò sotto /dev/mapper/, che eroga le funzionalità di cifratura (cryptsetup open) al dispositivo a blocchi fisico sottostante.
Infine, partiziono e/o formatto nella maniera canonica il dispositivo a blocchi virtuale (cifrato) /dev/mapper/.

Apertura

attacco il dispositivo, viene creata la entry per /dev/
attivo il dispositivo a blocchi virtuale che eroga le funzionalità di cifratura (cryptsetup open) e che creerà l’occorrenza sotto /dev/mapper/
faccio il mount del dispositivo a blocchi virtuale /dev/mapper/ su un punto di montaggio che è una cartella che creerò per l’occasione

Chiusura

faccio l’unmount del punto di montaggio
chiudo il dispositivo a blocchi virtuale (cryptsetup close) /dev/mapper/
stacco il dispositivo fisico

Fermo restando che questi restano i passaggi generali per qualunque dispositivo fisico, per creare un file container cifrato come farebbe Veracrypt, basta che cryptsetup formatti un file invece che un dispositivo a blocchi e automaticamente assocerà il file al primo loop device disponibile. È veramente semplice^[1].

Come creare il file vault

Divido le operazioni in 3 fasi:

Init: fase di inizializzazione del “dispositivo” (il file). Andrà fatta solo la prima volta.
Open e Close: sono le operazioni che farò ogniqualvolta dovrò usare il container.

Gli oggetti su cui andrà a lavorare sono:

disco_cifrato.img: il file container cifrato.
disco_cifrato: il nome con cui disco_cifrato.img (o meglio, la sua rappresentazione come loop device visibile con losetup) viene mappato da device mapper.
disco_in_chiaro: il punto di montaggio.

## Init
# creazione di una cartella che sarà il nostro punto di mount
mkdir disco_in_chiaro
 
# creazione di un file vuoto di 2 GiB
sudo fallocate -l 2g disco_cifrato.img
 
# preparazione cifratura LUKS 
sudo cryptsetup luksFormat \
     --type luks2 \
     --hash=sha512 \
     --key-size=512 \
     disco_cifrato.img
 
# creazione dispositivo a blocchi virtuale che eroga le funzionalità di cifratura
sudo cryptsetup open \
     --type luks2 \
     disco_cifrato.img disco_cifrato
 
# formattazione
sudo mkfs.ext4 /dev/mapper/disco_cifrato

## Open
# creazione dispositivo a blocchi virtuale
sudo cryptsetup open \
     --type luks2 
     disco_cifrato.img disco_cifrato
 
# monta il dispositivo nel punto di montaggio
sudo mount -t ext4 -o defaults /dev/mapper/disco_cifrato disco_in_chiaro

## Close
# smonta il dispositivo
sudo umount disco_in_chiaro
 
# chiudo il dispositivo a blocchi virtuale staccandolo dai loop device
sudo cryptsetup close disco_cifrato

Header detachable e keyfile

Alziamo il livello di paranoia aggiungendo una complessità ulteriore. Creeremo il file vault nel seguente modo:

il vault sarà inizializzato con rumore casuale
header detachable
offset custom
keyfile invece che password
default di argon2id (controlla il tuo default con cryptsetup benchmark)

L’apertura del volume cifrato sarà così vincolata alla disponibiltà sia del keyfile che dell’header, senza il quale il volume cifrato sarebbe comunque inservibile.

La presenza di rumore casuale su tutto il vault nella fase di inizializzazione impedirà qualunque tentativo di risalire alla tipologia di informazioni memorizzate, l'assenza di zeri impedirà di capire quanti sono i dati (cifrati) memorizzati.

L'offset custom aggiunge un ulteriore tassello perchè nasconde il punto in cui inizia il payload.

Un keyfile di dati binari casuali è infinitamente più robusto di una password e può esser conservato separatamente insieme all'header. La cifratura simmetrica del keyfile aggiunge ulteriore protezione, fatta magari usando una passphrase ottenuta col metodo Diceware.

Infine la cifratura di default di luks2, argon2id, che è notoriamente sia CPU bound che GPU bound.

Creo il keyfile protetto da una cifratura simmetrica di gpg^[2]:

## Creazione di un keyfile di 4KiB basata sulla pseudocasualità di /dev/urandom
# creazione del keyfile
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o disco_cifrato.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

Inizializzo il vault con dati casuali e poi lo formatto creando l'header detachable del volume cifrato fornendo il keyfile invece della passphrase classica:

# inizializzazione vault con dati casuali
# Apro il vault in modalità 'plain' senza header
sudo cryptsetup open \
    --type plain \
    --key-file /dev/urandom \
    --cipher aes-xts-plain64 \
    --key-size 512 \ 
    disco_cifrato.img container

# scrivo degli zeri a cui, attraverso il motore di cifratura,
# corrisponderanno dati casuali sul vault.
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# Formattazione vault
gpg -d disco_cifrato.key.gpg | \
    sudo cryptsetup luksFormat \
        --type luks2 \
        --key-file - \
        --header header.img \
        --offset 32768 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        disco_cifrato.img

Ed è così che l’apertura del volume cifrato è ora vincolata al possesso dell’header e del keyfile:

# attivazione dispositivo a blocchi virtuale passando header e keyfile protetto da gpg
gpg -d disco_cifrato.key.gpg | \
    sudo cryptsetup open \
        --type luks2 \
	--header header.img \
	--key-file - \
	disco_cifrato.img disco_cifrato

Provando ad aprire container cifrato senza fornire l’header (non tanto il keyfile che è una passphrase evoluta) succede questo:

sudo cryptsetup open \
    --type luks2 \
    disco_cifrato.img disco_cifrato
Il dispositivo disco_cifrato.img non è un dispositivo LUKS valido.

Infine, un'annotazione doverosa.

Visto che il livello di paranoia abbiamo detto essere elevato, sarebbe consigliabile prestare una certa attenzione alla scelta dei nomi.

Quelli usati finora avevano uno scopo “didattico”, che chiarisse il loro scopo con un nome parlante.

i nomi dei file relativi a header e keyfile sarebbe bene non fossero qualcosa del tpo “header.img” o “discocifrato_key.gpg” che rivelano troppo esplicitamente la presenza di un disco cifrato o addirittura dello stesso LUKS. Meglio usare nomi più decontestualizzati, che so... “sys-module-virtio.bin” per l'header e “boot-vmlinuz-06.blob” per il keyfile e via dicendo.

Partizionare un “volume” cifrato

Per concludere, visto che prima ho accennato al fatto che dm-crypt, grazie al sottosistema device mapper, fa in modo che i dispositivi a blocchi (virtuali) mascherino i dispositivo a blocchi sottostanti (un file montato su un loop device, nel nostro caso), i dispositivi a blocchi mappati possono anche essere partizionati invece che sempicemente formattati. O potrebbe essere volumi fisici di un gruppo di volumi LVM, and so on…

Difficilmente avremo bisogno di partizionare un file container cifrato, è solo l’occasione per speculare un po’ su quello che potrebbe succedere su un device fisico.

## Init
mkdir disco_in_chiaro
sudo fallocate -l 2g disco_cifrato.img
sudo cryptsetup luksFormat --hash=sha512 --key-size=512 disco_cifrato.img
sudo cryptsetup open --type luks2 disco_cifrato.img disco_cifrato
 
# Creo 1 partizione primaria da 600 MiB, una estesa da 1400 MiB
# contenente 2 partizioni logiche da 600 MiB e 829 MiB (mancano i
# 16 MiB dell'intestazione luks e i 3 MiB delle intestazioni delle
# partizioni primarie ed estese per un totale di 2GiB tondi tondi)
sudo fdisk /dev/mapper/disco_cifrato
n,,,,+600M,n,e,,,,n,,+600M,n,,,w
 
# il partizionamento potrebbe richiedere l'esecuzione di partprobe
# affinché il kernel carichi la tabella delle partizioni aggiornata
sudo partprobe /dev/mapper/disco_cifrato

# stato delle partizioni
sudo fdisk -l /dev/mapper/disco_cifrato
Disk /dev/mapper/disco_cifrato: 1,98 GiB, 2130706432 bytes, 520192 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x6d65a06f

Device                     Boot  Start    End Sectors  Size Id Type
/dev/mapper/disco_cifrato1         256 153855  153600  600M 83 Linux
/dev/mapper/disco_cifrato2      153856 520191  366336  1,4G  5 Extended
/dev/mapper/disco_cifrato5      154112 307711  153600  600M 83 Linux
/dev/mapper/disco_cifrato6      307968 520191  212224  829M 83 Linux

#procedo con la formattazione
sudo mkfs.ext4 /dev/mapper/disco_cifrato1 #formatto la partizione
sudo mkfs.ext4 /dev/mapper/disco_cifrato5 #formatto la partizione
sudo mkfs.ext4 /dev/mapper/disco_cifrato6 #formatto la partizione

Rispetto all’init di prima, invece che formattare subito il device “fisico”, l’ho partizionato. Esattamente come avrei fatto con un dispositivo realmente fisico.

## Open
sudo cryptsetup open --type luks2 disco_cifrato.img disco_cifrato
 
# di nuovo, potrebbe essere necessario a meno di non riavviare
sudo partprobe /dev/mapper/disco_cifrato
 
# mount delle partizioni
sudo mount -t ext4 -o defaults /dev/mapper/disco_cifrato1 disco_in_chiaro_1
sudo mount -t ext4 -o defaults /dev/mapper/disco_cifrato5 disco_in_chiaro_2
sudo mount -t ext4 -o defaults /dev/mapper/disco_cifrato6 disco_in_chiaro_3

## Close
sudo umount disco_in_chiaro_1
sudo umount disco_in_chiaro_2
sudo umount disco_in_chiaro_3
sudo cryptsetup close disco_cifrato1
sudo cryptsetup close disco_cifrato2
sudo cryptsetup close disco_cifrato5
sudo cryptsetup close disco_cifrato6
sudo cryptsetup close disco_cifrato

Note:

cryptsetup --open luks2 e cryptsetup --close luks2, quando applicate direttamente al file container, includono implicitamente la parte di accoppiamento al loop device. In altre parole,

cryptsetup open --type luks2 disco_cifrato.img disco_cifrato

equivale a

cryptsetup open --type luks2 $(losetup -Pf --show disco_cifrato.img) disco_cifrato

cryptsetup close --type luks2 disco_cifrato

equivale a^[↵]

cryptsetup close --type luks2 disco_cifrato
losetup -D

Se si incorre in questo errore usando gpg:
```
gpg: cancelled by user
gpg: error creating passphrase: Operation cancelled
gpg: symmetric encryption of '[stdin]' failed: Operation cancelled
```
vuol dire che la variabile d’ambiente GPG_TTY non ha lo stesso valore del comando tty. Per ovviare basta settare correttamente la variabile:
```
GPG_TTY=$(tty)
export GPG_TTY
```
come suggerito dalla documentazione GnuPG ^[↵]

#cryptsetup #devicemapper #dmcrypt #gpg #loseup #luks #lvm #loopdevice #storage