Cum pot descărcările neașteptate să vă provoace un computer Linux?

Sunt opriri neașteptate la fel de dăunătoare pentru Linux ca și alte sisteme de operare? Citiți în timp ce investigăm efectele opririi sistemelor catastrofale asupra sistemelor de fișiere Linux.

Sesiunea de întrebări și răspunsuri din ziua de astăzi vine de la amabilitatea SuperUser - o subdiviziune a Stack Exchange, o grupare bazată pe comunitate a site-urilor web Q & A.

Intrebarea

Cititorul SuperUser User208554 este curios despre structurile de fisiere Linux si este preocupat de o aplicatie / instalare pe care lucreaza:

Dezvolt o aplicație pe o placă încorporată de Linux (rulează Debian) de ex. Zmeura Pi, Beagle Board / Bone sau olimex. Plăcile lucrează într-un mediu în care energia electrică este tăiată în mod neașteptat (este prea complicat să se pună PSU etc.) și s-ar întâmpla în fiecare zi de câteva ori. Mă întreb dacă reducerile de energie neașteptate ar cauza probleme în sistemul de operare Linux? Dacă este ceva de care ar trebui să vă faceți griji, ce ați sugera pentru a preveni daunele pe sistemul de operare împotriva reducerilor neașteptate de putere?

PS. Aplicația trebuie să scrie unele date pe suportul de stocare (cardul SD), cred că nu ar fi potrivit să-l montezi ca o singură citire.

Deci, care este verdictul?

Răspunsul

Contribuitorul SuperUser l0b0 oferă câteva informații despre sistemele de fișiere jurnaliere / non-jurnalizate:

Acest lucru depinde de

1. dacă utilizați un sistem de fișiere de jurnalizare și
2. cât de bine aplicațiile sunt capabile să gestioneze procesarea avortată.

Luați în considerare, de exemplu, o aplicație care procesează un fișier și scrie rezultatele în timp ce acestea sunt calculate (o linie de ieșire pe linie de intrare) într-un alt fișier. Dacă se taie curentul în timpul procesării și aceeași aplicație se execută după repornire, nu se poate reporni doar procesarea de la începutul fișierului de intrare - ceea ce ar însemna că fișierul de ieșire va conține informații duplicate.

Ar putea fi foarte dificil să spui ceva definit despre un sistem complex ipotetic, dar cel mai stabil software-ul Linux pare să poată gestiona accidentele destul de bine.

Stu sugerează separarea sistemului de operare și a datelor, precum și adăugarea unei baterii de rezervă:

Pentru a minimiza posibilitatea corupției sistemului de operare, probabil că este mai bine să aveți separate partiții "sistem" și "date" pe cardul SD. În acest fel, puteți monta partiția "sistem" numai pentru citire și utilizați un FS foarte rezistent pe partiția "date".

În plus, majoritatea acestor plăci au cerințe de putere foarte scăzute, astfel încât este posibilă o baterie de rezervă. Placa "LiPo rider" pentru Raspberry Pi poate fi folosita ca un UPS de baza pentru a oferi o oprire clara a pierderii de putere.

În cele din urmă, Jenny D se extinde la sugestia privind sistemul de fișiere de jurnalizare:

Reducerile de curent neașteptate pot provoca deteriorarea datelor sistemului de fișiere - de ex. dacă un proces a început să scrie într-un fișier, dar nu a terminat încă să îl scrie, fișierul poate ajunge doar pe jumătate scris. Acum, imaginați-vă dacă întreruperea alimentării se întâmplă când sunteți la jumătatea drumului printr-o actualizare de kernel ...

După cum a scris l0b0, va fi utilă utilizarea unui sistem de fișiere de jurnalizare, deoarece va fi capabil să țină evidența a ceea ce a făcut de fapt. În plus față de informațiile despre wikipedia care au legătură cu l0b0, s-ar putea să fiți interesat de garantarea sistemelor de fișiere de jurnalism împotriva corupției, după o defecțiune de putere.

Sunteți, în calitate de programator, în mod evident, trebuie să aveți în vedere cu atenție cum să se ocupe de scrierea fișierelor, astfel încât să devină un proces atomic (adică este fie complet realizat, fie nu făcut deloc, dar niciodată făcut vreodată pe jumătate). Este o chestiune destul de complexă.

Aveți ceva de adăugat la explicație? Sunați în comentariile. Doriți să citiți mai multe răspunsuri de la alți utilizatori de tehnologie Stack Exchange? Check out discuția completă aici.