Fedora 26 - btrfs e blivet-gui install

In un torrido mese di agosto mi sono dilettato nel fare un paio di tentativi di partizionamento di un sistema con Fedora 26, utilizzando, in fase di installazione, blivet-gui.

Il sistema ha 2 dischi tradizionali da 1TB, uno (sda) con un'installazione funzionante di Windows 10, l'altro (sdb) è l'oggetto dell'installazione di Fedora. E' presente un vecchio bios, per cui le partizioni sono di tipo msdos e grub (un pezzo di grub) va inserito nell'mbr del disco sdb.

1) PRIMO ESPERIMENTO

- Una piccola partizione di boot da 1.5GiB ext4

- Un "volume btrfs" chiamato SYSTEM da 700GiB montato in /

- Una partizione di tipo btrfs da 220GiB cifrata e montata in /home (partizione e volume sono sinonimi in btrfs, ma blivet-gui differenzia: le partizioni si possono cifrare,  i volumi inspiegabilmente no. Sulle partizioni non puoi creare subvolume, sui volumi si).

- Vado poi a creare 4 subvolume di SYSTEM chiamati
gab-opt -> montato in /opt
gab-var -> montato in /var
gab-usr -> montato in /usr
gab-repo -> montato in /repo

Questa la situazione vista dal solito blivet-gui a installazione completata e a sistema avviato:

Considerazioni
Con questo partizionamento ho
- Una /home separata "fisicamente" e cifrata da 220GiB.
- Una / che è il subvolume di default (id=0) del volume btrfs SYSTEM. Questo volume ha vari sottovolumi montati in /opt /usr /repo etc che condividono lo stesso spazio del volume SYSTEM.

Subvolume

Questa strategia di partizionamento mi permette di creare molto agevolmente dei nuovi subvolume di SYSTEM.
Ho impiegato mentalmente parecchio tempo a conculdere che non sono obbligato a dare ai subvolume dei punti di montaggio e a vederli sempre come partizioni. In fase di installazione, dove c'è da rispettare la gerarchia del file system linux, ci può anche stare,ma ora, a sistema installato e avviato, posso anche evitare.
Per esempio: vado a creare un subvolume chiamato vm dove andrò a conservare le varie macchine virtuali di VirtualBox (ciascuna in una sottodirectory che potrebbe in futuro essere un suvbolume ulteriore).

Potrei montare il subvolume appena creato
ID 267 gen 73 top level 5 path vm
in una directory /GAB

ma questa operazione me la posso anche risparmiare e vivere serenamente con il solo subvolume (accessibile come una normalissima directory).

SNAPSHOTS

Tutto questo "casino" e la voglia di sperimentare con btrfs è finalizzata principlamente al poter creare degli snapshot.
Installo una macchina virtuale nel subvolume /vm.

Vado a creare uno snapshot iniziale di questa macchina virtuale.

Ora /vm e /vm-snap-orig sono identici (vm-snap-orig non occupa spazio, inizierà a occuparne quando inizierà a divergere da vm).

Faccio partire la macchina virutale e apporto qualche modifica alla stessa (banalmente, aggiungo un utente all'Ubuntu installato).

Creo un nuovo snapshot

Ora voglio tornare indietro alla situazione originale. Mi basta eliminare il subvolume vm e "rinominare" il primo snapshot.

L'elenco dei subvolume  certifica il successo dell'operazione

 

2) SECONDO ESPERIMENTO

- Una piccola partizione di boot da 1.5GiB ext4

- Un "volume btrfs" chiamato SYSTEM da 350GiB NON montato

- Un "volume btrfs" chiamato DATA da 470GiB NON montato

- Una partizione btrfs cifrata /home da 100GiB

All'interno del volume SYSTEM vado a creare dei subvolume che corrisponderanno alle partizioni "di sistema".
root -> montato in /
usr -> montato in /usr
var -> montato in /var
opt -> montato in /opt
Il subvolume 0 di default del volume SYSTEM non viene montato.

All'interno del volume DATA vado a creare dei subvolume che corrispondono alle partizioni dove conserverò i dati.
repo -> montato in /repo
vm -> montato in /vm

Considerazioni
A sistema installato e avviato vedrò questa situazione:

A prima vista questo esperimento 2  sembra molto più elegante dell'esperimento 1 e sopratutto, molto più rispondente a quella che dovrebbe essere la logica di btrfs: una scatola contenitore, all'interno della quale ci sono altre scatole "più piccole" ciascuna delle quali è una partizione della standard filesystem hierarchy di linux (FHS) con delle mie aggiunte personalizzate.

SUBVOLUME/SNAPSHOT

C'è però un grosso problema con qusto partizionamento, che riguarda la creazione di nuovi subvolume e snapshot. Se volessi infatti creare un nuovo subvolume di DATA non potrei farlo direttamente perchè DATA non ha il default subvolume (la root diciamo) montato.
Dovrei quindi  andare a montarlo; da qui vedrei i 2 subvolume e potrei  crearne uno nuovo.

Questo nuovo ipotetico subvolume che creo, una volta smontato DATA non lo vedrei in alcun luogo del mio file system e sarei costretto a montarlo esplicitamente in un mount point.

Stesso problema (e "soluzione") con gli snapshot, che altro non sono che dei subvolume con un contenuto iniziale.

Print Friendly, PDF & Email