Jurnal și ReiserFS
Odată cu lansarea versiunii 2.4 a Linux, a devenit posibilă utilizarea sistemului de fișiere cu proprietăți noi, cum ar fi Reiserfs, XFS, GFS și altele. Aceste sisteme de fișiere nu sunt încă testate suficient și există întrebări pe care le pot face exact, cât de bune sunt și cât de justificată este utilizarea lor într-un mediu Linux industrial. Daniel Robbins răspunde acestor întrebări în timpul explicării instalării acestor noi sisteme de fișiere avansate în Linux 2.4. În acest articol, primul articol din serii, explicațiile sunt date pentru reviste în general și în special pentru ReiserFS.
Ce să vă așteptați la citirea acestei serii de articole.
Acest lucru trebuie păstrat în minte. Cu toate acestea, deschiderea ciclului, sunt oarecum distras de obiectivul stabilit "practic" și am devotat o mică introducere "teoretică". Apoi, vor fi acoperite două subiecte care sunt foarte importante pentru comunitatea de dezvoltare Linux - "logging" și "technical" pentru proiectul ReiserFS. Jurnalizarea este o tehnologie care a așteptat mult timp și este timpul pentru utilizarea ei practică. ReiserFS, XFS, JFS, ext3 și GFS lucrează la această tehnologie. Este important să înțelegeți exact ceea ce face jurnalizarea și de ce Linux are nevoie de ea. Chiar dacă știi asta bine, sper că intro-ul meu de jurnal va fi util pentru tine. Acesta este un "pește" bun pentru explicarea tehnologiei altora și pentru practică. Deseori, procesul de implementare a unui nou trebuie să înceapă cu "Linux guy / gal", convingându-i pe alții de necesitatea unui "salt de calitate".
Introducere în jurnalism: meta-date
Să începem cu banal. Există sisteme de stocare pentru stocarea, găsirea și manipularea datelor. Pentru a efectua astfel de sarcini, sistemul de fișiere trebuie să aibă o structură internă "control", care să permită realizarea tuturor acestor operații. O astfel de structură internă ("datele despre date") se numește metadate. Organizarea acestor meta-date depinde de performanța sistemelor de fișiere (și de aceea sistemele de fișiere diferă una de alta).
De obicei, cu astfel de date metadate, utilizatorul nu interacționează. În schimb, driverul sistemului de fișiere funcționează cu ele. Driverul sistemului de fișiere Linux este conceput special pentru a gestiona acest labirint de metadate. Cu toate acestea, există o cerință importantă pentru funcționarea șoferului; el se așteaptă să vadă metadatele într-o stare rezonabilă, consecventă, nestăvilită. În caz contrar, accesul la fișiere devine imposibil.
Introducere în jurnal: fsck
Să vorbim despre fsck. Undeva la începutul boot-ului Linux, fsck este pornit și toate sistemele locale de fișiere sunt scanate (enumerate în / etc / fstab). Acest lucru este făcut pentru a asigura coerența metadatelor și, în cele din urmă, capacitatea de a monta sistemul de fișiere. O astfel de scanare durează mult timp și, cu scopul de a "salva", se presupune că este următorul. Dacă Linux termină lucrarea "corect", resetarea pe disc a tuturor datelor din memoria cache este "regulată". În acest caz, există o garanție că sistemul de fișiere este demontat "curat" și pregătit pentru o altă montare. De regulă, fsck este limitat doar la verificarea "drapelului de demontare curat" și, dacă nu există probleme, face o presupunere rezonabilă că cu meta-datele totul este OK.
Cu toate acestea, știm cu toții că există și situații de urgență din cauza unei căderi de tensiune sau a unei suspendări profunde a sistemului. În astfel de situații, nu este vorba despre o "dezinstalare curată", cu resetarea tuturor datelor memorate în cache pe disc. Dacă se întâmplă acest lucru, următoarea rulare de fsck detectează acest lucru și face o concluzie rezonabilă că sistemele de fișiere probabil că nu sunt pregătite să interacționeze cu driverul. Este foarte posibil ca meta-datele să fie într-o stare contradictorie.
Pentru a elimina posibilele consecințe, fsck va începe o scanare completă și va verifica coerența metadatelor, corectând multe erori de-a lungul drumului. În cele mai multe cazuri, după o "scanare patch", sistemul de fișiere este gata de montare. Trebuie înțeles că abilitatea de a monta nu înseamnă încă integritatea datelor în sine.
Probleme cu fsck
Nu se poate spune că metoda descrisă este o abordare proastă pentru asigurarea integrității sistemului de fișiere, dar soluția nu este optimă. Nu optimitatea este rezultatul faptului că fsck ar trebui să scaneze toate metadatele sistemului de fișiere pentru ieșirea consecvenței lor. Efectuarea unei scanări complete a tuturor metadatelor este o sarcină laborioasă. Trebuie adăugat că o creștere a dimensiunii fișierului a costurilor sistemului de o scanare completă a dezvolta în mod progresiv (pe o mașină de personal, acest lucru poate dura câteva minute până la o jumătate de oră sau mai mult de server). Și totuși, comportamentul implicit al fsck presupune verifica periodic după un anumit număr de „demontează curat“, care nu ar fi acceptabil pentru datacenter-misiune critică, atunci când „timpul - bani“. Din fericire, există o soluție mai bună.
Sistemele de fișiere Journaled rezolvă problema fsck printr-o structură de date suplimentară numită un jurnal. O astfel de revistă este o structură pe disc. Înainte ca șoferul sistemului de fișiere să schimbe meta-datele, se face o intrare în jurnal pentru a descrie acțiunile viitoare. Numai după aceasta metadatele se schimbă. Astfel, sistemul de fișiere jurnalizat servește fișierul jurnal al celor mai recente modificări ale metadatelor. Costul menținerii unui astfel de jurnal este incomparabil mai mic decât scanarea întregului sistem de fișiere pentru consistența metadatelor.
Imaginați-vă un lanț - datele stocate (lucruri), „date despre date“ (datele despre lucrurile) și o revistă cu o meta-meta-date (datele cu privire la datele despre chestii).
Jurnal în acțiune.
Acum să mergem la ReiserFS, primul din mai multe sisteme de fișiere jurnalizate care trebuie explorate. ReiserFS 3.6.x (versiunea pentru Linux 2.4) a fost dezvoltat de Hans Reiser și echipa lui Namesys. Hans și echipa sa propovăduiesc filosofia că cel mai bun sistem de fișiere este acela care formează un singur mediu public sau spațiu de nume. Într-un astfel de mediu, aplicațiile pot interacționa mai flexibil, mai eficient și mai puternic. Pentru a realiza acest lucru, sistemul de fișiere trebuie să îndeplinească o parte din activitatea prestată în mod tradițional de aplicații. Prin această abordare, utilizatorii pot continua să folosească în mod direct sistemul de fișiere în loc să creeze nivele cu scop special, cum ar fi bazele de date etc.
Lucrați cu fișiere mici.
Cum se întâmplă cu introducerea unui număr mare de mici informații în sistemul de fișiere? Namesys au decis, cel puțin pentru început, să se concentreze asupra unui aspect al muncii sistemului de fișiere - lucrul cu fișiere mici. În mod strict vorbind, sistemele de fișiere precum ext2 și ufs în acest domeniu se comportă ineficient, determinând adesea dezvoltatorii să proiecteze baze de date sau să folosească alte "trucuri" pentru a obține performanțe satisfăcătoare. Această abordare conduce la "inventarea unei multitudini de biciclete" și generează un număr imens de API-uri incompatibile pentru un scop strict specializat.
Vom înțelege și din cauza a ceea ce ext2 încurajează acest tip de programare "biciclete". Ext2 este bun pentru stocarea unui număr destul de mare de fișiere mai mari de douăzeci kilobytes fiecare, dar nu este deloc ideal pentru stocarea a 2000 de fișiere de 50 de octeți. Mai mult decât atât, a redus semnificativ performanțele, dar și stocarea de fișiere mici de pe ext2 duce la utilizarea ineficientă a spațiului pe disc, astfel încât ext2 alocă pentru fiecare fișier de numere întregi blocuri 1-2-4 KB (dimensiune bloc este setat când formarea sistemului de fișiere).
Înțelepciunea obișnuită a lumii ne spune să nu stocăm multe fișiere ridicol de mici direct pe sistemul de fișiere. În schimb, există ideea de stocare a informațiilor într-o bază de date care rulează pe sistemul de fișiere. Ca răspuns, Hans Reiser ar spune că ori de câte ori se creează un nivel peste sistemul de fișiere, arată doar că sistemul de fișiere nu corespunde nevoilor noastre. Dacă este satisfăcut, ar putea fi refuzat. Prin urmare, un sistem de fișiere bine proiectat economisește timpul de dezvoltare și elimină codul incompatibil.
Dar aceasta este tot teoria. Și cum funcționează ReiserFS în practică cu un număr mare de fișiere mici? Surprinzător, dar foarte bun. De fapt, ReiserFS atunci când procesează fișiere mai mici decât un K câștigă în viteza ext2 în opt până la cincisprezece ori! În general, ReiserFS depășește ext2 în aproape fiecare domeniu, dar într-adevăr strălucește în comparație cu procesarea fișierelor mici.
Tehnologia ReiserFS
Datorită faptului că ReiserFS funcționează efectiv cu fișiere mici? ReiserFS utilizează un arbore b * echilibrat special (unul pe sistemul de fișiere) pentru a organiza toate datele sistemului de fișiere. Numai aceasta oferă o creștere semnificativă a performanței și, de asemenea, elimină o serie de limitări artificiale privind aspectul sistemului de fișiere. De exemplu, devine posibil să aveți un director care să conțină 100.000 de alte subdirectoare. Un alt avantaj de a folosi b * copac este că ReiserFS, la fel ca cele mai multe alte nouă generație de fișiere sisteme de fișiere, alocă în mod dinamic inodes în loc de un set static format în timpul creării sistemului de fișiere „tradiționale“. Acest lucru oferă o mai mare flexibilitate și optimitate în formarea spațiului de stocare.
ReiserFS are, de asemenea, o serie de caracteristici care vizează în special îmbunătățirea lucrului cu fișiere mici. ReiserFS nu este obligat de o limitare în alocarea memoriei pentru un fișier în întregul număr de blocuri 1-2-4 KB. Dacă este necesar, poate fi alocată o dimensiune exactă pentru fișier. ReiserFS include și o oarecare optimizare specială a fișierelor "cozi" pentru stocarea părților finale ale fișierelor mai mici decât blocul de sisteme de fișiere. Pentru a mări viteza, ReiserFS capabile să stocheze fișiere de conținut direct în b * copac, mai degrabă decât un pointer la un bloc de disc (în ext2 este FastLink conceptul, atunci când conținutul „soft“ link-uri de 60 de octeți este stocat în inode).
Astfel sunt realizate două lucruri. În primul rând, performanța crește foarte mult, deoarece datele și informațiile stat_data (inode) pot fi stocate unul lângă celălalt și pot fi citite de o operație de disc IO. În al doilea rând, ReiserFS este capabil să împacheteze cozile, economisind spațiu pe disc. De fapt, cu permisiunea ReiserFS de a efectua împachetarea cozilor (valoarea implicită), aceasta va economisi aproximativ șase la sută din spațiul de pe disc (în comparație cu ext2).
Trebuie avut în vedere că ambalarea cozilor necesită o muncă suplimentară, deoarece modificarea dimensiunii fișierelor necesită "reambalare". Din acest motiv, în ReiserFS, ambalajul coada poate fi dezactivat, permițând administratorului să aleagă între viteza și eficiența utilizării spațiului de pe disc.
ReiserFS este un sistem de fișiere excelent. Următorul articol va descrie procesul de instalare a ReiserFS sub Linux 2.4. Se va descrie procedura de reglare optimă pentru cerințele de aplicație, opțiunile de kernel și altele.
Despre autor
Locuind in Albuquerque, New Mexico, Daniel Robbins este presedintele / CEO al Gentoo Technologies, Inc. și creatorul Gentoo Linux. un Linux avansat pentru PC și sistemul Portage, un sistem de porturi de generație următoare pentru Linux. De asemenea, a contribuit la editarea cărților Macmillan Caldera OpenLinux Unleashed. SuSE Linux Unleashed. și Samba dezlănțuită. Daniel a fost implicat în computere într-o oarecare modă încă de la clasa a doua, când a fost expus pentru prima dată pe siglă. Acest lucru explică, probabil, de ce a fost desemnat Artist Graphic Artist la SONY Electronic Publishing / Psygnosis. Daniel se bucură să petreacă timp cu soția lui, Mary, și cu noua sa fiică, Hadassah. Puteți contacta Daniel la [email protected].
Trimiteți-le prietenilor: