Sistem de fișiere cu jurnalizare

Sistemele de fișiere cu jurnalizare sunt sistemele de fișiere care păstrează un istoric (jurnal, în engleză log) al modificărilor efectuate, istoric actualizat înainte de operarea modificărilor pe sistemul de fișiere. Această tehnică reduce cu mult probabilitatea de corupere a sistemului de fișiere în urma unei pene de curent sau a unei erori în sistem.

Motivații

Actualizarea sistemelor de fișiere pentru a reflecta modificările aduse fișierelor și directoarelor necesită multe operații separate de scriere. Acestea introduc un race condition pentru care o întrerupere (cum ar fi o pană de curent sau o cădere a sistemului) ce are loc între scrieri poate lăsa datele într-o stare intermediară invalidă.

De exemplu, ștergerea unui fișier într-un sistem de fișiere Unix implică doi pași:

Ștergerea înregistrării din cadrul directorului.
Marcarea spațiunui fișierului și inode-ului său ca fiind liberi în tabela de spațiu liber.

Dacă sistemul cade între pașii 1 și 2, va rămâne un inode orfan, și astfel o pierdere de spațiu de stocare. Pe de altă parte, dacă se efectuează doar pasul 2 înainte de cădere, fișierul neșters încă va fi marcat ca fiind liber și ar putea fi suprascris la o scriere ulterioară pe disc.

Într-un sistem de fișiere fără jurnalizare, detectarea și recuperarea din astfel de inconsistențe necesită o parcurgere completă a structurilor de date. Aceasta poate dura mult timp dacă sistemul de fișiere este mare sau dacă accesul la el se face cu o lărgime de bandă redusă.

Un sistem de fișiere cu jurnalizare păstrează un jurnal al modificărilor pe care intenționează să le efectueze, înainte de efectuarea lor. După o cădere, recuperarea implică doar reefectuarea modificărilor aflate în jurnal până când sistemul redevine consistent. Modificările sunt astfel atomice (sau indivizibile) prin aceea că fie au succes (au avut succes dinainte de cădere sau au fost reefectuate cu succes la recuperare), fie nu sunt reefectuate deloc (sunt sărite, deoarece nu au apucat să fie scrise complet în jurnal).

Optimizări

Unele sisteme de fișiere permit creșterea, reducerea dimensiunii și realocarea jurnalului, ca și în cazul unui fișier normal; dar majoritatea își păstrează jurnalul într-o zonă contiguă, sau într-un fișier ascuns, despre care se știe ca nu își va schimba locul sau dimensiunea la montarea sistemului de fișiere.

Un jurnal fizic păstrează copii ale blocurilor ce urmează a fi scrise, așa cum este cazul cu Ext3fs.^[1] Un jurnal logic păstrează doar informații despre modificări într-un format compact special, cum este cazul la XFS și la NTFS. Aceasta reduce cantitatea de date ce trebuie citită și scrisă din și în jurnal, dar folosește operații mari, cu metadate.

Unele implementări de UFS evită jurnalizarea și implementează în schimb actualizări soft: comandă scrierile în așa fel încât sistemul de fișiere de pe disc nu este niciodată inconsistent, sau încât singura inconsistență ce poate fi creată în caz de cădere este o pierdere de spațiu de stocare. Pentru a recupera aceste pierderi, tabela de spațiu liber este reactualizată în urma unei verificări complete a sistemului de fișiere efectuată la următoarea montare. Acest procedeu de garbage collection este adesea efectuat în fundal.^[2]

Jurnalizarea doar cu metadate

Jurnalizarea poate avea un impact puternic asupra performanței, deoarece necesită ca toate datele să fie scrise de două ori.^[3] Jurnalizarea cu metadate este un compromis între siguranță și performanță. În acest caz se stochează în jurnal doar niște metadate. Aceasta asigură că sistemul poate fi recuperat rapid la următoarea montare, dar coruperea datelor poate avea loc deoarece datele nejurnalizate și metadatele din jurnal pot să ajungă să fie desincronizate.

De exemplu, adăugarea la un fișier pe un sistem de fișiere Unix implică trei pași:

Creșterea mărimii fișierului în inode-ul său.
Alocarea de spațiu pentru extensie din tabela de spațiu liber.
Scrierea datelor adăugate în spațiul proaspăt alocat.

Într-un jurnal cu metadate, pasul 3 nu mai este înregistrat. Dacă pasul 3 nu se efectuează, dar pașii 1 și 2 sunt reefectuați în timpul recuperării, fișierului i se vor adăuga date eronate.

Cache-ul de scriere, în multe sisteme de operare, își stochează scrierile pentru maximizarea vitezei. Pentru a evita un hazard de scriere out-of-order în cazul unui jurnal cu metadate, scrierea datelor în fișier trebuie să fie ordonată în așa fel încât să fie trimisă la dispozitivul de stocare înainte de scrierea metadatelor asociate. Aceasta poate fi dificil de implementat deoarece necesită coordonare în cadrul nucleului sistemului de operare între driverul sistemului de fișiere și cache-ul de scriere. Un hazard de scriere "out-of-order" poate exista și în cadrul sistemului de stocare, dacă acesta:

nu poate efectua scrieri atomice ale blocurilor, sau
își schimbă ordinea scrierilor, sau
nu onorează cererile de golire a cache-ului de scriere.

Exemple

UNIX

Linux

Mac OS

HFS+

Windows

NTFS

Note

^ Tweedie, Stephen C (1998). „Journaling the Linux ext2fs Filesystem” (PDF). The Fourth Annual Linux Expo. Arhivat din original (PDF) la 30 septembrie 2007. Accesat în 22 septembrie 2008. .
^ Seltzer, Margo I; Ganger, Gregory R; McKusick, M Kirk. „"Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems"”. 2000 USENIX Annual Technical Conference. USENIX Association. .
^ Prabhakaran, Vijayan; Arpaci-Dusseau, Andrea C; Arpaci-Dusseau, Remzi H. „Analysis and Evolution of Journaling File Systems” (PDF). 2005 USENIX Annual Technical Conference. USENIX Association. .

[1] Tweedie, Stephen C (1998). „Journaling the Linux ext2fs Filesystem” (PDF). The Fourth Annual Linux Expo. Arhivat din original (PDF) la 30 septembrie 2007. Accesat în 22 septembrie 2008. .

[2] Seltzer, Margo I; Ganger, Gregory R; McKusick, M Kirk. „"Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems"”. 2000 USENIX Annual Technical Conference. USENIX Association. .

[3] Prabhakaran, Vijayan; Arpaci-Dusseau, Andrea C; Arpaci-Dusseau, Remzi H. „Analysis and Evolution of Journaling File Systems” (PDF). 2005 USENIX Annual Technical Conference. USENIX Association. .

[1]

[2]

[3]