Prezentul și viitorul jurnalizării

Există multe definiții ale sistemelor de fișiere de jurnalizare, dar să dăm o formulare pe care toată lumea o poate înțelege: jurnalizat Sistemul de fișiere- acesta este un sistem pentru cei care s-au săturat de program verificări fsckîn timpul încărcării. Acesta este, de asemenea, un sistem pentru cei care sunt aproape de ideea sistemelor tolerante la eșec. Dacă opriți incorect alimentarea sistem normal unde nu există înregistrare, sistemul de operare detectează acest fapt și rulează utilitarul de verificare a integrității discului fsck când următorul boot. Acest utilitar scanează sistemul de fișiere și încearcă să remedieze problemele fără a afecta datele. Procesul de verificare poate dura destul de mult. Uneori, sistemul de fișiere devine atât de deteriorat încât sistemul de operare pornește numai în modul utilizator unic și solicită utilizatorului să efectueze o recuperare ulterioară.

Spune fsck

Ceea ce este și mai rău este că procesul fsck poate rula sistem de operare automat la montarea sistemului de fișiere pentru a vă asigura că metadatele sunt corecte (chiar dacă nu a existat nicio corupție). Prin urmare, eliminarea verificărilor inutile ale integrității sistemului de fișiere este un domeniu vizibil de îmbunătățire.

Deci acum știi cine are nevoie de jurnalizarea sistemelor de fișiere, de ce astfel de sisteme nu au nevoie de verificări fsck? Pe scurt, pentru că țin un jurnal special. Un jurnal este un fișier care este un buffer inel în care sunt înregistrate toate acțiunile legate de modificările sistemului de fișiere. Periodic, aceste modificări sunt aplicate sistemului de fișiere. În cazul unei erori, jurnalul poate fi folosit ca punct de plecare pentru a recupera datele nesalvate și pentru a preveni coruperea metadatelor.

Pentru a rezuma, un sistem de fișiere jurnal este un sistem de fișiere tolerant la accident în care comenzile de modificare sunt înregistrate înainte de a fi executate, evitând astfel coruperea metadatelor. (A se vedea figura 1). Ca de obicei cu Linux, există multe variante ale unor astfel de sisteme. Hai sa facem scurtă recenzie istoricul sistemelor de fișiere și apoi uitați-vă la sistemele de fișiere disponibile astăzi și diferențele dintre acestea.

Ce sunt metadatele?

Metadate sunt numite structuri de date de serviciu necesare pentru stocarea datelor de bază. Operațiuni precum crearea și ștergerea unui fișier și director, creșterea unui fișier, trunchierea unui fișier etc. afectează metadatele.

Figura 1. Un sistem de fișiere jurnal tipic.

Istoria sistemelor de fișiere jurnalizate Linux

IBM® a fost primul care a dezvoltat un sistem de fișiere de jurnal numit JFS (Journaled Sistemul de fișiere). Prima versiune a JFS a fost introdusă în 1990 și versiune modernă acceptat pe Linux ca JFS2, dezvoltat ulterior. În 1994, Silicon Graphics a introdus sistemul de fișiere XFS de înaltă performanță pentru sistemul de operare IRIX. În 2001, XFS a fost portat pe Linux. În 1998, a fost dezvoltat un sistem bazat pe fișiere pentru sistemele Amiga. Sistem inteligent File System (SFS), care a fost ulterior lansat sub Licența publică generală minoră GNU (LGPL) și a primit suport în Linux 2005. Cel mai utilizat sistem de fișiere este ext3fs (din engleză. al treilea sistem de fișiere extins), care este o extensie a sistemului ext2 cu adăugarea de logare. Suportul ext3fs a apărut în Linux în 2001. În cele din urmă, sistemul de fișiere jurnal utilizat pe scară largă ReiserFS a deschis multe căi și oportunități noi de dezvoltare. Cu toate acestea, dezvoltarea acestui sistem a încetinit din cauza problemelor juridice ale autorului său.

Tipuri de logare

Toate sistemele de fișiere jurnalizate mențin un jurnal pentru a tampona modificările sistemului de fișiere (care este, de asemenea, necesar pentru recuperare în caz de dezastru), dar există strategii diferite pentru ce să vă înregistrați și când. Cele mai comune trei strategii sunt modul writeback, modul de comandă și modul de date.

ÎN modul writeback Doar metadatele sunt înregistrate în jurnal, iar blocurile de date sunt scrise direct pe disc. Acest lucru contribuie la inviolabilitatea structurii sistemului de fișiere și protejează împotriva daunelor, dar deteriorarea datelor în sine este încă posibilă (de exemplu, dacă are loc o blocare a sistemului după scrierea metadatelor în jurnal, dar înainte de scrierea unui bloc de date). Decide problema specificată permite modul de comandă. În acest mod, numai metadatele sunt de asemenea înregistrate, dar datele în sine sunt scrise înainte ca metadatele să fie înregistrate. Acest lucru asigură consecvența datelor sistemului de fișiere după recuperare. În cele din urmă, este posibil să vă autentificați modul de date, în care sunt înregistrate atât metadatele, cât și datele în sine. Acest mod are cel mai inalt nivel rezistență la deteriorare și pierdere de date, dar are dezavantajul performanței scăzute, deoarece toate datele sunt scrise de două ori (mai întâi în jurnal, apoi pe disc).

Regulile de aplicare a modificărilor înregistrate în jurnal pot fi, de asemenea, diferite în abordări diferite. De exemplu, când ar trebui aplicate modificările? Când este plină revista? Sau când expiră un anumit timeout?

Sisteme de fișiere jurnalizate astăzi

Astăzi, sunt utilizate în mod activ mai multe sisteme de fișiere de jurnal, fiecare dintre ele având propriile avantaje și dezavantaje. Mai jos sunt cele mai populare patru sisteme de fișiere de jurnal.

JFS2

JFS2 (cunoscut și ca sistem de fișiere de jurnal îmbunătățit) este primul sistem de fișiere jurnalizat și pentru o lungă perioadă de timp a fost utilizat pe sistemul de operare IBM AIX® înainte de a fi portat pe Linux. JFS2 este un sistem de fișiere pe 64 de biți care, luând rădăcinile din JFS original, a fost îmbunătățit semnificativ în ceea ce privește scalabilitatea și suportul pentru arhitecturile multiprocesor.

JFS2 acceptă jurnalizarea în ordine, performanță ridicată și timpi de recuperare sub secunde. Pentru a îmbunătăți performanța, folosește o metodă de plasare a fișierelor bazată pe extindere. Plasare bazată pe extindereînseamnă plasarea fișierului în mai multe secțiuni continue, mai degrabă decât în ​​multe blocuri identice. Datorită continuității, aceste zone oferă mai mult citire rapidăși înregistrare. Beneficiu suplimentar extents - costuri mai mici pentru lucrul cu metadate. Când plasați un fișier în blocuri, metadatele fiecărui bloc sunt înregistrate. Dacă sunt folosite extensii, metadatele pentru extensii, care de obicei constau din mai multe blocuri, se modifică.

JFS2 folosește și arbori B+ pentru ambele căutare eficientă directoare și pentru a gestiona descriptorii de măsură. JFS2 nu are propria politică pentru împingerea modificărilor pe disc - în schimb se bazează pe expirarea demonului kupdate.

XFS

XFS este un alt sistem de fișiere de jurnalizare timpurie, dezvoltat inițial de Silicon Graphics în 1995 pentru sistemul de operare IRIX. În 2001, XFS a fost implementat în Linux, fiind deja un sistem de fișiere bine gândit și de încredere la acea vreme.

XFS utilizează adresarea completă pe 64 de biți și oferă performanțe foarte înalte prin utilizarea arborilor B+ pentru a găzdui directoare și fișiere. XFS stochează datele ca extensii, acceptând dimensiuni variabile (de la 512 octeți la 64 kiloocteți). Împreună cu extents, XFS utilizează alocare leneșă, care întârzie alocarea blocurilor până când este timpul să le scrieți pe disc. Această caracteristică crește probabilitatea de a umple mai multe blocuri de disc la rând, deoarece numărul acestora va fi cunoscut în momentul înregistrării.

Alte proprietăți interesante ale XFS sunt viteza I/O garantată atunci când utilizatorilor sistemului de fișiere li se alocă o rezervă lățime de bandă pentru operațiuni I/O și I/O direct, care copiază datele direct între disc și buffer-ul aplicației (în loc să treacă prin mai multe buffer-uri). Jurnalizarea în XFS se face folosind metoda writeback.

Al treilea sistem de fișiere extins (ext3fs)

Al treilea sistem de fișiere extins (ext3fs) este cel mai popular sistem de fișiere de jurnal, care a apărut ca o evoluție a binecunoscutului sistem de fișiere ext2. De fapt, este compatibil cu ext2, deoarece funcționează pe structuri identice, dar cu adăugarea unui buștean. Mai mult, este posibil să montați o partiție ext3 ca ext2 sau să convertiți ext2 în ext3 folosind utilitarul tune2fs.

ext3fs acceptă toate cele trei strategii de înregistrare ( scrie înapoi, modul de comandă și de date), dar este utilizat modul de comandă implicit. Politica de transfer a datelor de jurnal pe disc poate fi configurată, dar inițial este astfel încât transferul să aibă loc fie când 1/4 din jurnal este plin, fie când expiră unul dintre cronometrele de transfer.

Unul dintre principalele dezavantaje ale ext3fs provine din faptul că inițial nu a fost intenționat să fie un sistem de fișiere de jurnal. Deoarece se bazează pe ext2fs, îi lipsesc multe dintre caracteristicile avansate găsite în alte sisteme de fișiere (cum ar fi extents). Și ea arată de obicei performanta slabaîn comparație cu ReiserFs, JFS și XFS, dar utilizează mai puțin CPU și memorie decât multe alte sisteme de fișiere.

ReiserFS

Ce este compactarea sterilului?

Se întâmplă adesea ca fișierul să aibă o dimensiune dimensiune mai mică bloc logic. În loc să aloci un întreg bloc pentru fiecare astfel de fișier, lăsând o parte a blocului neocupată (această parte se numește coadă), încearcă să încadreze mai multe fișiere într-un singur bloc. Această metodă oferă un câștig de 5% spatiu liber comparativ cu alte sisteme de fișiere, dar are un impact negativ asupra performanței.

Sistemul de fișiere ReiserFS a fost conceput de la bun început pentru a fi jurnalizat. În 2001, a fost adăugat la ramura principală a nucleului 2.4 și a devenit primul sistem de fișiere de jurnal care a apărut în Linux. Principala metodă de jurnalizare este organizarea. Este acceptată extinderea în timp ce dimensiunea sistemului de fișiere. ReiserFS acceptă, de asemenea compactarea sterilului pentru a reduce în mod dinamic fragmentarea, ceea ce îi permite să depășească ext3fs atunci când lucrează cu fișiere mici.

ReiserFS (numit și ReiserFS v3) folosește multe abordări moderne, de exemplu arbori B+. Formatul sistemului de fișiere se bazează pe un singur arbore B+, făcând operațiunile de căutare deosebit de rapide și scalabile. Politica de migrare a jurnalului pe disc depinde de dimensiunea jurnalului și se bazează pe numărul de blocuri care trebuie migrate.

Reputația ReiserFS a fost afectată de mai multe ori: cel mai recent de problemele autorului sistemului cu legea ( informatii detaliate vezi sectiunea).

Viitorul sistemelor de fișiere jurnalizate

După ce am văzut sistemele de fișiere jurnalizate din prezent și trecut, să ne uităm la ce ne rezervă viitorul (și ce nu).

Reiser4

După ce a introdus cu succes ReiserFS în nucleu și a fost folosit în multe distribuții Linux Namesys (compania din spatele ReiserFS) a început să lucreze la un nou sistem de fișiere jurnal, Reiser4, care a fost construit în întregime de la zero și include multe funcții avansate.

Înregistrarea îmbunătățită în Reiser4 este realizată prin utilizarea scrierilor rătăcitoare și amânarea alocării blocurilor până când datele de jurnal sunt migrate (cum s-a făcut în XFS). Arhitectura Reiser4 includea suport flexibil pentru pluginuri (pentru a adăuga funcționalitate de compresie sau criptare, de exemplu), dar această idee a fost respinsă de comunitatea Linux, care credea că aceste caracteristici avansate aparțin subsistemului virtual de fișiere (VFS).

După punerea sub acuzare a proprietarului Namesys și, în același timp, a autorului ReiserFS, toate activitățile comerciale din jurul Reiser4 au fost suspendate.

Al patrulea sistem de fișiere extins

Al patrulea sistem de fișiere extins (ext4fs) este o dezvoltare ulterioară a ext3fs. Ext4fs a fost conceput ca un înlocuitor pentru ext3fs, având direct și compatibil invers, dar include multe îmbunătățiri (dintre care unele încalcă această compatibilitate). În practică, puteți monta o partiție ext4 ca ext3 și invers.

În primul rând, ext4fs este un sistem de fișiere pe 64 de biți cu suport pentru volume uriașe (până la 1 exabyte). Poate folosi și extensii, dar în acest caz își pierde compatibilitatea cu ext3fs. Similar cu XFS și Reiser4, ext4fs întârzie plasarea blocurilor pe disc și are loc la nevoie (ceea ce reduce fragmentarea). Jurnalul stochează și sume de control continut pentru o mai mare fiabilitate. În loc de arbori B+- sau B*-, este folosit varietate deosebită B-copaci, așa-numiți H-arborele, care permite subdirectoarelor să aibă mult mai multe marime mai mare(în ext3 este limitat la 32Kb).

Deși alocarea leneșă reduce fragmentarea, în timp sistemul de fișiere marime mareîncă fragmente. Pentru a rezolva această problemă, a fost dezvoltat utilitarul e4defrag, care poate fi folosit pentru defragmentare fişiere separate sau un întreg sistem de fișiere.

O altă diferență interesantă între ext4fs și ext3fs este acuratețea marcajelor de timp ale fișierelor. În ext3, dimensiunea marcajului de timp este de o secundă. Ext4fs se uită către viitor: cu creșterea continuă a vitezelor și interfețelor procesorului, mai mult măsurare precisă. Prin urmare, o nanosecundă a fost luată ca dimensiune de timp.

Deși ext4fs este inclus în Nucleul Linuxîn versiunea 2.6.19, poate fi deja considerat stabil. Acest sistem, care este încă în curs de dezvoltare, este Punct de start pentru a crea sistemul de fișiere jurnal al viitorului în Linux.

Trecând peste

Sistemele de fișiere jurnalizate oferă fiabilitate și protecție împotriva coruperii datelor în cazul unui accident al sistemului sau al pierderii alimentării. În plus, timpul de recuperare în astfel de sisteme este mult mai rapid decât în ​​sistemele de fișiere tradiționale (de exemplu, cele care folosesc fsck). Dezvoltarea de noi metode de înregistrare se bazează atât pe experiența anterioară venită de la JFS și XFS, cât și pe căutarea de noi algoritmi și structuri. Nu este complet clar cum vor evolua sistemele de fișiere jurnalizate în viitor, dar utilitatea lor este evidentă și au devenit deja noul standard pentru sistemele de fișiere.

Sistemul de fișiere standard original pentru Linux a fost Ext2fs. Ext2 se bazează pe structura i-node. Nodul I conține informații despre fișier și pointeri către blocurile de date în care se află fișierul. Pentru a îmbunătăți performanța I/O, datele sunt localizate temporar în memorie cu acces aleator. Problema apare dacă apare o eroare înainte ca datele din cache să fie scrise pe disc. Acest lucru cauzează o inconsecvență în sistemul de fișiere. De exemplu, apare o legătură către un fișier care nu a fost încă creat pe disc sau fișierele au fost deja șterse, dar nodurile lor și blocurile de date rămân pe disc. Fsck (Verificarea sistemului de fișiere – verificarea sistemului de fișiere) – program standard pentru a rezolva neconcordanțe. Singura cale pentru a face acest lucru este să scanați întregul disc și să verificați toate dependențele dintre i-noduri, blocuri de date și conținutul directorului. Odată cu creșterea volumelor de disc, această procedură a început să dureze o cantitate mare timp - problema serioasa pentru servere care trebuie să ruleze constant.

Asta a devenit Motivul principal introducerea tehnologiei de tranzacții preluate din baze de date și tehnologie de recuperare în sistemele de fișiere, iar acest lucru a condus la apariția sistemelor de fișiere de jurnalizare.

Un sistem de fișiere jurnalizat este un sistem de fișiere tolerant la blocări, în care integritatea datelor este garantată deoarece actualizările metadatelor fișierelor sunt înregistrate pe disc înainte ca orice modificare a structurii sistemului de fișiere să fie făcută. În cazul unui eșec, un sistem de fișiere jurnalizat asigură recuperarea tuturor datelor pierdute. Cea mai comună abordare este metoda de jurnalizare sau înregistrare a metadatelor fișierelor. Esența sa este că informațiile despre orice modificare sunt scrise într-o zonă rezervată a sistemului de fișiere și numai după aceea se face modificarea în sine.

Când reporniți un computer care utilizează un sistem de fișiere jurnalizat, programul de montare poate asigura integritatea sistemului de fișiere prin simpla verificare a jurnalului pentru modificări care au fost așteptate, dar care nu au fost făcute și scriindu-le în sistemul de fișiere. În cele mai multe cazuri, sistemul nu trebuie să verifice integritatea sistemului de fișiere, ceea ce înseamnă că computerul va fi disponibil pentru lucru aproape imediat după o repornire. În consecință, șansele de pierdere a datelor din cauza problemelor din sistemul de fișiere sunt reduse semnificativ.

Linux are trei FS principale jurnalizate: ReiserFS de la Namesys, XFS de la SGI și Ext3, dezvoltat de Stephen Tweedie, care a ajutat la crearea Ext2.

Cel mai simplu mod de a îmbunătăți performanța față de sistemele tradiționale Unix este evitarea utilizării liste aferente sau bitmap-uri, care au o problemă de scalabilitate și nu sunt potrivite pentru discuri noi cu capacități uriașe. Toate sistemele noi folosesc arbori echilibrați (B-Trees) sau o variantă a acestora (B+Trees).

Un arbore este format din noduri interne și frunze. Fiecare nod este un bloc de disc. Fiecărui obiect (fișier, director) i se atribuie o cheie unică, similară cu numărul inodului din alte sisteme de fișiere. Nodurile interne constau în principal din chei și pointeri către noduri copii. Nodul care pornește arborele este cunoscut ca rădăcină; Nodurile care stau la capătul unei ramuri de copac sunt uneori numite frunze.

Timpul de căutare în B+Trees nu este proporțional cu numărul de obiecte (fișiere dintr-un director sau cu numărul de blocuri de pe un disc), ci cu logaritmul acestui număr. Într-un copac echilibrat, toate ramurile (căile de la rădăcină la frunză) au aceeași lungime (sau aproximativ aceeași).

ReiserFS se bazează pe B+Tree în organizarea obiectelor sistemului de fișiere. ReiserFS oferă doar înregistrarea metadatelor. În cazul unei reporniri neplanificate, datele din blocurile utilizate în timpul unei defecțiuni pot fi corupte, astfel încât ReiserFS nu garantează că datele vor rămâne intacte după o eroare.

ReiserFS are, de asemenea, o serie de caracteristici care vizează în mod special îmbunătățirea performanței cu fișiere mici. Unul dintre caracteristici speciale ReiserFS este Tail Packing. Tail este un fișier a cărui dimensiune este mai mică decât un bloc logic sau unele părți ale fișierelor care ocupă mai puțin de un bloc. Pentru a economisi spațiu liber, ReiserFS folosește compresia fișierelor de coadă și aceasta permite cu aproximativ 5% mai mult spațiu liber în comparație cu Ext2. Pentru a crește viteza, ReiserFS este capabil să stocheze conținutul fișierelor direct în interiorul b*tree, mai degrabă decât ca un pointer către un bloc de disc.

XFS a fost creat la începutul anilor 90 (1992–1993) de Silicon Graphics (acum SGI) pentru calculatoare multimedia cu Irix OS. Sistemul de fișiere a fost foarte orientat fișiere mariși sisteme de fișiere. La 1 mai 2001, SGI a lansat prima versiune a XFS pentru Linux.

Pentru a crește scalabilitatea fișierelor sisteme XFS folosește B+Trees pe scară largă. XFS permite stocarea jurnalului pe un alt dispozitiv bloc.

XFS are o caracteristică numită alocare întârziată - în loc să aloce blocuri într-un fișier așa cum este scris în cache, XFS pur și simplu rezervă blocuri în sistemul de fișiere, plasând datele în extensii virtuale speciale. Când întregul fișier este conținut în memorie, acesta poate fi de obicei plasat într-o singură bucată de contiguu spatiu pe disc. Acest lucru previne fragmentarea fișierelor.

Dimensiunea maximă a fișierului - 9 milioane TB

În ReiserFS, o repornire neașteptată poate duce la o fișier mutabil fragment dintr-o dată fișier la distanță. Pe lângă pierderea evidentă de date, acest lucru ar putea avea consecințe mai grave ipotetic. XFS are garanția că orice blocuri „subscrise” sunt umplute cu zerouri. Deoarece blocurile cu zero octeți în fișiere de sistem sunt ignorate, lacuna de securitate este eliminată.

Ext3 este un supliment pentru Ext2. Pe de o parte, vă permite să păstrați un jurnal al operațiunilor pentru mai multe recuperare rapida. Dar acest sistem de fișiere moștenește unele limitări de la Ext2 (de exemplu, este bazat pe blocuri și folosește forța brută atunci când caută fișiere și directoare) și, prin urmare, nu poate fi numit un sistem de fișiere de jurnal pur.

Jurnalul poate fi localizat pe orice alt sistem de fișiere. Este posibil să aveți mai multe sisteme de fișiere Ext3 cu un jurnal partajat.

Tipuri de înregistrare acceptate de Ext3, care pot fi activate din fișierul /etc/fstab:

• data=journal (modul de jurnalizare a datelor complete) – toate datele noi sunt mai întâi scrise în jurnal și numai după aceea sunt transferate în locația sa permanentă. În cazul unui accident, jurnalul poate fi recitit, readucerea datelor și metadatele la o stare constantă. Cel mai lent, dar cel mai de încredere.
• data=ordered – sunt înregistrate doar modificările aduse metadatelor sistemului de fișiere, dar în mod logic metadatele și blocurile de date sunt grupate într-un singur modul numit tranzacție. Înainte ca noile metadate să fie scrise pe disc, blocurile de date asociate sunt scrise mai întâi. Acest mod este setat implicit. Când adăugați date la sfârșitul unui fișier, modul data=ordonat este garantat pentru a asigura integritatea (ca și în modul de jurnalizare a datelor complete). Cu toate acestea, dacă datele sunt scrise într-un fișier peste cele existente, atunci există posibilitatea de a amesteca blocurile „originale” cu cele modificate. Acesta este un rezultat al datelor=ordonate care nu urmăresc înregistrările unde bloc nou se află deasupra celui existent și nu provoacă modificarea metadatelor.
• data=writeback (numai metadate) – sunt scrise doar modificările aduse metadatelor sistemului de fișiere. Cel mai metoda rapida Logare. Același lucru cu cel folosit în XFS și ReiserFS.

Fişier sistem NTFSși-a început existența cu Windows NT 3.5 în 1993. Poate gestiona discuri de până la câteva sute de terabytes.

Fiecare fișier dintr-un volum NTFS este reprezentat de o intrare în dosar special, numit tabelul de fișiere master (MFT) fisierul principal masa). Prima intrare din acest tabel descrie tabelul principal de fișiere în sine;

Aceasta este urmată de înregistrarea în oglindă MFT. Dacă prima intrare MFT este coruptă, atunci NTFS citește a doua intrare pentru a găsi fișierul MFT în oglindă.

A treia înregistrare MFT este fișierul jurnal; conține o listă de pași ai tranzacției utilizați de sistemul de fișiere jurnal pentru a recupera fișierele în cazul unei erori. A șaptesprezecea și următoarele intrări din tabelul fișierului principal sunt utilizate de fișierele și directoarele reale.

Fișierele și directoarele mici pot fi conținute în întregime într-o intrare de tabel de fișiere master. Directoarele mari sunt organizate în arbori B, având intrări cu pointeri către clustere externe care conțin intrări de directoare care nu au putut fi scrise în structura MFT.

Jurnalizarea NTFS

NTFS folosește jurnalizarea structuri logice, și nu datele utilizatorului - de unde și fraza că siguranța datelor nu este garantată, dar, cu toate acestea, starea corectă a sistemului în sine va fi menținută. Faptul că NTFS nu înregistrează date din fișierul jurnal duce în practică la un scenariu de pierdere a datelor - în același caz ipotetic de scriere a trei megaocteți, dacă procesul de scriere eșuează, nu va fi niciodată posibil să se determine care parte a datelor a fost scrisă și care a rămas neschimbată. Operațiunile care sunt totuși înregistrate de sistem sunt operațiuni cu structurile sistemului însuși, adică cu fișiere și directoare: adăugarea fișierelor, redenumirea, mutarea, crearea și ștergerea (eliberarea spațiului liber). Operațiunile de defragmentare sunt de asemenea înregistrate - adică mutarea fragmentelor de fișiere. Într-un cuvânt, totul operatii logice logat.

Înregistrare întârziată și puncte de control Logare

Se știe că orice sistem modern a mari viteza operațiuni cu fișiere este forțat să folosească stocarea în cache, inclusiv memorarea în cache a operațiunilor de scriere. Așa-numita scriere leneșă este un principiu de stocare în cache în care datele destinate a fi scrise pe disc sunt stocate în cache pentru o perioadă de timp și sunt salvate fizic doar în timpul liber de la alte activități. Scrierile lenețe îmbunătățesc semnificativ eficiența operațiunilor de pe disc, deoarece astfel de stocare în cache grupează multe operațiuni într-una singură - acest lucru este deosebit de eficient dacă scrierile sunt efectuate în zone compacte ale discului. Un alt avantaj al scrierii leneșe este că nu interferează cu operațiunile de citire mai necesare și scrie doar atunci când sistemul este liber și nu are nevoie de acces la disc pentru alte nevoi. Cum să reconciliezi scrierea întârziată cu înregistrarea în jurnal? Aceasta este o întrebare destul de dificilă, deoarece amânarea unei scrieri face posibilă pierderea datelor care erau în coadă pentru înregistrarea fizicăși nu a avut timp să scrie pe disc înainte de defecțiune. Cel mai neplăcut lucru aici nu este nici măcar pierderea de date, ci faptul că există o nepotrivire în timpul de înregistrare: unele zone de servicii pot fi actualizate, dar unele zone aferente nu pot încă, deoarece actualizarea lor ar putea fi amânată cu încă câteva secunde. și nu va avea loc din cauza unui eșec.

NTFS depășește aceste probleme prin integrarea semnificativă a scrierilor leneșe și a jurnalizării. Când încercați să începeți o operațiune înregistrată, intenția este imediat scrisă în jurnal - de exemplu, pentru a șterge un fișier. Acest lucru se întâmplă fără întârziere - în această etapă, scrierea leneșă nu funcționează: acesta este un cost al prezenței în jurnal care nu poate fi evitat. Dar toate celelalte operațiuni sunt deja într-un mod întârziat - adică pot avea loc parțial sau să nu aibă loc deloc. Singura operațiune întârziată, a cărei operare este oarecum diferită de o simplă scriere, este scrierea în jurnal despre finalizarea cu succes a tranzacțiilor anterioare, așa-numitul punct de control. La anumite intervale - de obicei la fiecare câteva secunde - sistemul trebuie să șteargă pe disc absolut toate operațiunile întârziate. După finalizarea acestei operațiuni, în jurnal se scrie următoarele: cea mai simplă notație- un punct de control, care indică faptul că toate operațiunile anterioare au fost efectuate corect la toate nivelurile - atât logice, cât și fizice.

Acest mod de operare - cu ajutorul înregistrărilor și punctelor de control - pe de o parte, garantează în continuare complet funcţionare corectăînregistrarea în jurnal și, pe de altă parte, practic nu duce la încetinirea activității: verificarea se face, aproape instantaneu, iar scrierea în jurnal despre începerea operațiunii corespunde în costurile forței de muncă cu scrierea datelor în sine, fără cache întârziată. Înregistrarea propriu-zisă, efectuată ulterior, în marea majoritate a cazurilor nu interferează cu nicio operațiune și nu dăunează performanței sistemului.

La munca regulata sistem de fișiere, toate modificările sunt de obicei imediat făcute pe disc (sau mai degrabă, în memoria cache a discului din sistemul de operare, dar acest lucru nu este important în acest context).

Multe operațiuni necesită modificări simultane ale mai multor structuri ale sistemului de fișiere ( metadate. Un exemplu simplu: atunci când creați un hardlink, trebuie să creșteți simultan numărul de link-uri către inode și să modificați conținutul directorului către care este făcută legătura Nu puteți face doar una dintre aceste operații - conținutul sistemului de fișiere va fi incorectă.

În timpul funcționării normale a sistemului de fișiere, o astfel de operație complexă este întotdeauna efectuată în întregime, cu excepția cazului în care codul de implementare a sistemului de fișiere conține erori critice. Cu toate acestea, dacă există o repornire anormală sau defecțiune hardware această situație este foarte reală.

Deoarece după repornire nu știm ce operațiuni au fost efectuate, ce a fost neterminat, dar știm doar că discul nu a fost demontat corect (în acest caz, așa-numitul steag murdar este resetat), trebuie să analizăm sistemul de fișiere pe întregul disc și, astfel, identificați toate erorile din sistemul de fișiere și corectați-le. Desigur, nu este întotdeauna posibil să faceți acest lucru automat (inteligența nenaturală, din păcate, nimeni nu a putut încă să predea abilități de clarviziune), prin urmare același fsck.ext2 după o repornire anormală poate necesita intervenție manuală.

Cei care au rulat fsck pe o partiție de 100-200 G (ceea ce este departe de a fi neobișnuit în zilele noastre) înțeleg perfect că este puțină plăcere în asta. Administratorii de matrice multi-terabyte, pentru un minut în plus de timp inactiv, pot să li se smulgă capul „accidental” la cuvântul fsck, să apuce valeriană sau să ceară să nu înjure cu astfel de cuvinte în prezența lor.

Pentru a rezolva această problemă, o idee genială a fost inventată cu mult timp în urmă (dacă știe cineva când și de către cine, vă rog să-mi spuneți) - la început scrieți o descriere a operațiunii planificate pe disc și abia apoi executați-o. Apoi, va fi posibil să nu testați întregul disc pentru corectitudine, ci doar să vă limitați la vizualizarea conținutului jurnalului și, dacă operațiunea nu a fost finalizată, apoi să o faceți înapoi. Pentru a face acest lucru, nu trebuie să rulați fsck - acest lucru este făcut de driverul sistemului de fișiere însuși.

Pentru a rezuma, singurul lucru pe care îl poate și ar trebui să facă un sistem de fișiere jurnal este să economisească timp pe fsck. În consecință, consistența metadatelor sistemului de fișiere este garantată, nici mai mult, nici mai puțin.

Prețul acestei plăceri: avem o zonă de disc mică (măsurată de obicei în zeci de megaocteți), care reprezintă capacitate maximă, acesta este performanță maximă, măsurat în numărul de operațiuni I/O pe secundă, este în scădere. Ei bine, desigur, se consumă puțin spațiu pe disc, ceea ce în epoca discurilor prețuri< 1$/гигабайт никого не волнует.

Înregistrarea datelor

După cum ați observat, operațiunile cu metadate sunt de obicei scrise în jurnal. Cu toate acestea, puteți face același lucru cu datele.

Din câte știu, numai ext3 cu parametrul data=journal poate efectua înregistrarea datelor pe Linux.

Desigur, înregistrarea datelor în multe cazuri reduce oarecum performanța (dar nu toate; pe site-ul IBM există rezultate ale testelor conform cărora utilizarea înregistrării datelor pentru sistemele de fișiere pe care se află bazele de date poate chiar să crească performanța).

Totuși, acest instrument nu garantează siguranța datelor, din experiența mea experienta personala utilizarea ext3 cu data=journal este cel mai fiabil sistem de fișiere.

Performanţă

Un cititor atent va fi observat probabil că utilizarea unui jurnal creează o încărcare neuniformă pe disc - o zonă mică (în comparație cu dimensiunea totală a sistemului de fișiere) reprezintă o cantitate disproporționată de operațiuni.

Există două soluții foarte interesante:
În primul rând, puteți duce revista la disc separat(majoritatea sistemelor de fișiere permit acest lucru), rezultatul este că dublăm efectiv performanța prin adăugarea unui singur disc. Arată deosebit de frumos când performanța unei matrice RAID uriașă este crescută într-un mod atât de simplu și ieftin.

În al doilea rând, puteți folosi carduri speciale memorie nevolatilă (de exemplu UMEM, pe care, din păcate, nu l-am văzut la vânzare în Rusia), care sunt, de asemenea, vizibil mai rapide decât discurile convenționale (dar au o dimensiune de memorie mică).

Există și o soluție complet extravagantă pe care nu am încercat-o încă - faceți un jurnal pe un dispozitiv bloc situat în memorie. Desigur, după o repornire, un astfel de sistem de fișiere va trebui recreat din nou, dar pentru datele temporare acest lucru poate oferi o creștere interesantă și vizibilă a performanței. Mai ales când se înregistrează date, nu doar metadate.

Trucuri

După cum ați văzut deja, revista poate oferi și o creștere a vitezei. Există câteva trucuri mai ingenioase pe care un sistem de fișiere de jurnal le poate folosi pentru a continua mărire mai mare performanţă:

• crearea amânată a fișierului (la momentul creării fișierului, nu creați imediat o intrare în director, ci păstrați-o doar în jurnal pentru o perioadă de timp; poate că fișierul este temporar și va fi șters imediat);

• alocarea întârziată a fișierelor (nu alocați fizic spațiu nici măcar pentru primul bloc al fișierului până când trebuie să scrieți cel puțin un bloc), este foarte posibil ca utilizatorul să modifice mai întâi dimensiunea fișierului și abia apoi să înceapă să scrie date. Ca rezultat, fragmentarea este redusă (dacă programele folosesc acest truc);

Acestea sunt cele mai simple, există multe alte trucuri care permit unui sistem de fișiere jurnal să funcționeze mai rapid decât unul obișnuit, rămânând în același timp mai fiabil.

Defecte

După cum am spus deja, jurnalul nu este un panaceu, iar datele nu salvează deloc. Cu toate acestea, mulți oameni obțin un fals sentiment de securitate din utilizarea sistemelor de fișiere jurnalizate - desigur, puteți reporni mașina resetând-o și nici măcar nu va jura când se încarcă!

Da, nu va jura. Și va fi absolut corect din punctul de vedere al unui sistem de fișiere fsck. Doar datele pot rămâne în continuare doar cu resturi.

Să spunem că reiserfs înăuntru situatii similare S-ar putea să lase gunoi în fișierele modificate (date arbitrare care au fost în blocul alocat fișierului). Ceea ce, în esență, înseamnă o scurgere accidentală foarte probabilă de informații.

XFS acționează mai corect - scrie astfel de blocuri ca zerouri. Ceea ce șochează adesea utilizatorii. Mai ales fanii reiserfs, care nu vor scrie zerouri.

Ca urmare, reiserfs sunt mai probabile va salva modificări, iar XFS va face tot posibilul pentru a evita gunoiul în fișiere și scurgerile de date - doar strategii ușor diferite. Rezultatul este același - datele se pot pierde și nici măcar nu veți ști despre asta. Până dai de un dosar pe care nimeni nu s-a atins de un an de zile (era în arhivă), și care se dovedește brusc a fi plin de gunoi sau zerouri.

ext3 cu înregistrarea datelor activată nu suferă de astfel de caracteristici. Cu toate acestea, pierde semnificativ în performanță.

Într-un sens bun, toate aceste probleme pot (și ar trebui) să fie evitate pur și simplu prin achiziționarea UPS-ului și este mai bine să folosiți înregistrarea ca un nivel suplimentar de fiabilitate și un mijloc de creștere a productivității.

Concluzie

Un sistem de fișiere jurnal face doar administrarea puțin mai ușoară, dar nu este un remediu magic pentru pierderea de date din cauza repornirilor anormale. Prin urmare, dacă nu utilizați UPS și nu faceți Backup, atunci mai devreme sau mai târziu datele dumneavoastră vor fi acoperite cu un bazin de cupru, ceea ce sincer NU vă doresc. Și dacă doriți, puteți utiliza sisteme de fișiere jurnalizate ca mijloc de creștere a productivității.

Cine a cumpărat UPS și backup face ca datele să fie întotdeauna intacte

(C) Denis Smirnov 5 noiembrie 2004
Postarea acestui document pe alte resurse de pe Internet, precum și în publicații tipărite, nu este permisă.

NTFS este un sistem tolerant la erori care se poate restabili cu ușurință la o stare corectă în cazul aproape oricărei defecțiuni reale. Orice sistem de fișiere modern se bazează pe conceptul de tranzacţie- o acțiune efectuată în întregime și corect sau deloc executată. NTFS pur și simplu nu are stări intermediare (eronate sau incorecte) - cantitatea de modificare a datelor nu poate fi împărțită în înainte și după eșec, aducând distrugere și confuzie - este fie comisă, fie anulată.

Exemplul 1: datele sunt scrise pe disc. Dintr-o dată se dovedește că nu a fost posibil să scriem în locul în care tocmai ne-am hotărât să scriem următoarea porțiune de date - deteriorarea fizică a suprafeței. Comportamentul NTFS în acest caz este destul de logic: tranzacția de scriere este anulată în întregime - sistemul realizează că scrierea nu a fost efectuată. Locația este marcată ca eșuată, iar datele sunt scrise într-o altă locație - începe o nouă tranzacție.

Exemplul 2: Un caz mai complex este atunci când datele sunt scrise pe disc. Brusc, alimentarea este oprită și sistemul repornește. În ce fază s-a oprit înregistrarea, unde sunt date și unde nu? Un alt mecanism de sistem vine în ajutor - jurnalul de tranzacții. Faptul este că sistemul, realizându-și dorința de a scrie pe disc, a marcat această stare în metafișierul $LogFile. La repornire, acest fișier este examinat pentru prezența tranzacțiilor neterminate care au fost întrerupte de un accident și al căror rezultat este imprevizibil - toate aceste tranzacții sunt anulate: locul în care s-a făcut scrierea este marcat din nou ca liber, indici și elemente MFT. sunt readuse la starea în care se aflau înainte de eșec, iar sistemul în ansamblu rămâne stabil. Ei bine, ce se întâmplă dacă a apărut o eroare în timpul scrierii în jurnal? De asemenea, este în regulă: tranzacția fie nu a început încă (există doar o încercare de a înregistra intențiile de a o efectua), fie s-a încheiat deja - adică există o încercare de a înregistra că tranzacția a fost deja deja efectuat. În acest din urmă caz, la următoarea pornire, sistemul însuși va înțelege pe deplin că, de fapt, totul a fost scris corect oricum și nu va acorda atenție tranzacției „nefinalizate”.

Totuși, rețineți că înregistrarea în jurnal nu este un panaceu absolut, ci doar un mijloc de a reduce semnificativ numărul de erori și defecțiuni ale sistemului.

Experiența arată că NTFS este restabilit la o stare complet corectă chiar și în cazul unor defecțiuni în momentele foarte aglomerate cu activitatea discului. Puteți chiar să optimizați discul și să apăsați pe resetare în mijlocul acestui proces - probabilitatea de pierdere a datelor chiar și în acest caz va fi foarte mică. Este important să înțelegem, totuși, că sistemul Recuperare NTFS garantează corectitudinea Sistemul de fișiere, nu datele dvs. Dacă ați scris pe un disc și ați avut o blocare, este posibil ca datele dvs. să nu fie scrise, dar există întotdeauna o copie a acestora.

Comprimare

Fișierele NTFS au un atribut destul de util - „comprimat”. Faptul este că NTFS are suport încorporat pentru compresia discului - ceva pentru care anterior trebuia să folosești Stacker sau DoubleSpace. Orice fișier sau director poate fi stocat individual pe disc sub formă comprimată - acest proces este complet transparent pentru aplicații. Comprimarea fișierelor are o viteză foarte mare și o singură proprietate negativă mare - uriașa fragmentare virtuală a fișierelor comprimate, care, totuși, nu deranjează pe nimeni. Comprimarea se realizează în blocuri de 16 clustere și utilizează așa-numitele „clustere virtuale” - din nou o soluție extrem de flexibilă care vă permite să obțineți efecte interesante- de exemplu, jumătate din fișier poate fi comprimat, dar jumătate nu. Acest lucru se realizează datorită faptului că stocarea informațiilor despre comprimarea anumitor fragmente este foarte similară cu fragmentarea obișnuită a fișierelor: de exemplu, o înregistrare tipică a aspectului fizic pentru un fișier real, necomprimat:

clusterele de fișiere de la 1 la 43 sunt stocate în clustere de discuri începând de la 400

clusterele de fișiere de la 44 la 52 sunt stocate în clustere de discuri începând de la 8530...

Aspectul fizic al unui fișier comprimat tipic:

clusterele de fișiere de la 1 la 9 sunt stocate în clustere de discuri începând de la 400

clusterele de fișiere de la 10 la 16 nu sunt stocate nicăieri

clusterele de fișiere de la 17 la 18 sunt stocate în clustere de discuri începând de la 409

clusterele de fișiere de la 19 la 36 nu sunt stocate nicăieri

Este clar că fișier comprimat are clustere „virtuale”, în care nu există informații reale. De îndată ce sistemul vede astfel de clustere virtuale, înțelege imediat că datele din blocul anterior, un multiplu de 16, trebuie decomprimate, iar datele rezultate vor umple doar clusterele virtuale - acesta este, de fapt, întregul algoritm. .