News Ticker

OpenSUSE Tumbleweed: transactional update

 

OpenSUSE Tumbleweed, nella sua corsa di innovazione, il 21 gennaio ha rilasciato un aggiornamento molto interessante del suo sistema di… aggiornamento!

Infatti è stato integrato uno script per gestire i transactionale updates (aggiornamenti a transazione, ma useremo il termine inglese che ci sembra più preciso), descritto con le seguenti caratteristiche:

  • è atomico (ovvero è possibile vederlo come un’azione unica in un tempo breve, e non una serie di azioni in fasi successive)
  • l’aggiornamento non influenza il sistema attivo (quindi tutti i programmi continuano a lavorare come prima dell’aggiornamento finché non viene applicato per davvero)
  • o è applicato con successo o non succede niente (non sono possibili stati intermedi di aggiornamenti installati a metà)
  • si può tornare indietro facilmente

Questi punti producono anche un altro effetto: se anche fosse stato installato correttamente l’aggiornamento, ma si dimostrasse incompatibile per qualche motivo, il ritorno alla situazione precedente diventerebbe facile e veloce.

Come funzionano questi update in OpenSUSE? In pratica sfruttano a piene mani la funzionalità di snapshot di Btrfs, ovvero la capacità di creare un punto oltre il quale le modifiche al filesystem sono fatte senza sovrascrivere i dati esistenti. Così, se necessario, si torna indietro; l’installazione verrà effettuata in una nuova snapshot, che al riavvio sarà resa attiva (e solo allora gli aggiornamenti saranno effettivi). Se tutto è a posto, la nuova situazione sarà resa corrente dimenticando di quando è stata creata la snapshot, altrimenti con un altro riavvio sarà possibile ripristinare la situazione precedente.
Diventa evidente che l’uso di quel particolare filesystem diventa essenziale (cosa di cui preoccuparsi all’installazione, ma già da un po’ è la configurazione standard per OpenSUSE), ma anche che il tutto prevede sempre almeno un riavvio.

Tutto bello, usabile e pronto? No. Nello stesso annuncio vengono indicati dei problemi di questa implementazione, e in particolare che se viene confermata la bontà dell’aggiornamento (come abbiamo scritto, dimenticando il punto di snapshot) si perde la capacità di tornare indietro; se quindi qualche aggiornamento non dovesse risultare problematico subito la caratteristica così allettante di rollback semplicemente sparisce. Inoltre la snapshot è preparata per essere attiva dopo il riavvio, quindi qualsiasi lavoro svolto (scritto su disco) tra quando è pronta la snapshot e quando si riavvia il sistema viene semplicemente perso.
Sono descritti anche altri problemi più tecnici o specifici (dal come si comportano i pacchetti RPM attuali all’uso di subvolumes di Btrfs), che se siete abbastanza intrepidi (o semplicemente curiosi) consigliamo di leggere.

Questa nuova tecnologia, quindi, sembra molto promettente ma ancora un po’ acerba, cosa che sa anche SUSE tanto da non averla abilitata di default. In attesa però che sia sviluppata fino a renderla utilizzabile, magari eliminando la necessità dei reboot, fateci sapere se l’avete provata. Noi, prima o poi, un giro lo faremo… 😉