Come possono gli arresti imprevisti danneggiare un computer Linux?

Arresti inattesi sono dannosi per Linux come lo sono per altri sistemi operativi? Continua a leggere mentre analizziamo gli effetti di arresti di sistema catastrofici su file system Linux.

La sessione di domande e risposte di oggi ci viene fornita per gentile concessione di SuperUser, una suddivisione di Stack Exchange, un raggruppamento di siti Web di domande e risposte basato sulla comunità.

La domanda

Il lettore SuperUser User208554 è curioso delle strutture di file Linux e si preoccupa di un'app / installazione su cui sta lavorando:

Sto sviluppando un'applicazione su una scheda embedded Linux (esegue Debian) ad es. Raspberry Pi, Beagle Board / Bone, o olimex. Le schede funzionano su un ambiente in cui l'elettricità viene interrotta in modo imprevisto (è troppo complicato posizionare l'alimentatore, ecc.) E succederebbe ogni giorno un paio di volte. Mi chiedo se le interruzioni di alimentazione impreviste potrebbero causare problemi al sistema operativo Linux? Se è qualcosa di cui dovrei preoccuparmi, cosa suggeriresti di prevenire i danni all'OS contro le interruzioni di corrente impreviste?

PS. L'applicazione deve scrivere alcuni dati sul supporto di memorizzazione (scheda SD), penso che non sarebbe adatto a montarlo come di sola lettura.

Quindi qual è il verdetto?

La risposta

Il contributore SuperUser l0b0 offre alcune informazioni sui file system di journaling / non-journaling:

Questo dipenderà da

1. se stai usando un file system di journaling e
2. quanto bene le applicazioni sono in grado di gestire l'elaborazione abortita.

Si consideri ad esempio un'applicazione che elabora un file e scrive i risultati non appena vengono calcolati (una riga di output per riga di input) in un altro file. Se l'alimentazione viene interrotta durante l'elaborazione e la stessa applicazione viene eseguita dopo il riavvio, non può semplicemente riavviare l'elaborazione dall'inizio del file di input, il che significherebbe che il file di output conterrebbe informazioni duplicate.

Potrebbe essere molto difficile dire qualcosa di definitivo su un ipotetico sistema complesso, ma il software Linux più stabile sembra essere in grado di gestire gli arresti in modo abbastanza piacevole.

Stu suggerisce di separare il sistema operativo e i dati, oltre ad aggiungere un backup della batteria:

Per ridurre al minimo la possibilità di corruzione del sistema operativo, è probabilmente meglio avere partizioni separate di "sistema" e "dati" sulla scheda SD. In questo modo è possibile montare la partizione "sistema" in sola lettura e utilizzare un FS altamente resiliente nella partizione "dati".

Inoltre, la maggior parte di queste schede ha requisiti di alimentazione molto bassi, quindi è possibile un backup della batteria. La scheda "LiPo rider" per Raspberry Pi può essere utilizzata come UPS base per fornire un arresto pulito in caso di mancanza di alimentazione.

Infine, Jenny D espande il suggerimento del file system di journaling:

Interruzioni di alimentazione impreviste possono causare il danneggiamento dei dati del file system, ad es. se un processo ha iniziato a scrivere su un file, ma non ha ancora finito di scriverlo, il file potrebbe finire solo per metà. Ora immagina se l'interruzione di corrente si verifica quando sei a metà dell'aggiornamento del kernel ...

Come ha scritto l0b0, l'uso di un file system di journaling aiuterà, poiché sarà in grado di tenere traccia di ciò che è stato effettivamente ottenuto. Oltre alle informazioni di wikipedia collegate da l0b0, potresti essere interessato a Garantire la corruzione del journaling dei filesystem anche dopo un'interruzione di corrente.

Come programmatore, ovviamente, è necessario considerare attentamente come gestire la scrittura sui file in modo che diventi un processo atomico (vale a dire che è completamente fatto o non fatto affatto, ma mai a metà). È un problema abbastanza complesso.

Hai qualcosa da aggiungere alla spiegazione? Sound off nei commenti. Vuoi leggere più risposte dagli altri utenti di Stack Exchange esperti di tecnologia? Controlla la discussione completa qui.