Unix File System - Unix File System

Sistemul de fișiere Unix ( UFS ) este un sistem de fișiere acceptat de multe sisteme de operare Unix și similare Unix . Este un descendent îndepărtat al sistemului de fișiere original utilizat de versiunea 7 Unix .

Ulterior Berkeley Fast File System (numit și BSD Fast File System - FFS ) a fost folosit în Unixes, care nu este același cu UFS.

Proiecta

Un volum UFS este compus din următoarele părți:

• Câteva blocuri la începutul partiției rezervate blocurilor de boot (care trebuie inițializate separat de sistemul de fișiere)
• Un superbloc, care conține un număr magic care îl identifică ca un sistem de fișiere UFS și alte câteva numere vitale care descriu geometria și statisticile acestui sistem de fișiere și parametrii de reglare comportamentală
• O colecție de grupuri de cilindri. Fiecare grup de cilindri are următoarele componente:
  • O copie de rezervă a superblocului
  • Un antet al grupului de cilindri, cu statistici, liste gratuite etc., despre acest grup de cilindri, similar cu cele din superbloc
  • Un număr de inode , fiecare conținând atribute de fișier
  • Un număr de blocuri de date

Inodurile sunt numerotate secvențial, începând de la 0. Inodul 0 este rezervat pentru intrările de director nealocate, inodul 1 a fost inodul fișierului blocat defect în versiunile istorice UNIX, urmat de inodul pentru directorul rădăcină , care este întotdeauna inodul 2 și inodul pentru directorul pierdut + găsit care este inodul 3.

Fișierele din director conțin doar lista numelor de fișiere din director și inodul asociat fiecărui fișier. Toate metadatele fișierului sunt păstrate în inode.

Istorie și evoluție

Primele versiuni ale sistemelor de fișiere Unix au fost denumite pur și simplu FS . FS a inclus doar blocul de boot, superblocul, un grup de inoduri și blocurile de date. Acest lucru a funcționat bine pentru discurile mici pentru care Unix-urile au fost concepute timpuriu, dar pe măsură ce tehnologia a avansat și discurile au crescut, mișcând capul înainte și înapoi între grupul de inoduri și blocurile de date la care au făcut referire au provocat zdrobire . Marshall Kirk McKusick , pe atunci student Berkeley , a optimizat FFS (Fast File System) BSD 4.2 inventând grupuri de cilindri, care împart discul în bucăți mai mici, fiecare grup având propriile sale inoduri și blocuri de date.

Intenția BSD FFS este de a încerca să localizeze blocurile de date și metadatele asociate în același grup de cilindri și, în mod ideal, tot conținutul unui director (atât date, cât și metadate pentru toate fișierele) din același grup de cilindri sau din apropiere, astfel reducerea fragmentării cauzate de împrăștierea conținutului unui director pe un întreg disc.

Unii dintre parametrii de performanță din superbloc au inclus numărul de piste și sectoare, viteza de rotație a discului, viteza capului și alinierea sectoarelor între piste. Într-un sistem complet optimizat, capul ar putea fi mutat între piesele apropiate pentru a citi sectoarele împrăștiate din piesele alternative în timp ce așteptați ca platoul să se învârtă.

Pe măsură ce discurile au crescut din ce în ce mai mult, optimizarea la nivel de sector a devenit învechită (în special cu discurile care au folosit numerotarea liniară a sectorului și sectoare variabile pe pistă). Cu discuri mai mari și fișiere mai mari, citirile fragmentate au devenit mai mult o problemă. Pentru a combate acest lucru, BSD a mărit inițial dimensiunea blocului sistemului de fișiere de la un sector la 1 K în 4.0 BSD; și, în FFS, a mărit dimensiunea blocului sistemului de fișiere de la 1 K la 8 K. Acest lucru are mai multe efecte. Șansa ca sectoarele unui fișier să fie contigue este mult mai mare. Cantitatea de cheltuieli generale pentru listarea blocurilor fișierului este redusă, în timp ce numărul de octeți reprezentabil de un anumit număr de blocuri este mărit.

Sunt posibile, de asemenea, dimensiuni mai mari, deoarece numărul maxim de blocuri este limitat de un număr fix de blocuri cu lățime de biți. Cu toate acestea, cu dimensiuni mai mari de blocuri, discurile cu multe fișiere mici vor pierde spațiu, deoarece fiecare fișier trebuie să ocupe cel puțin un bloc. Din această cauză, BSD a adăugat fragmentarea la nivel de bloc , numită și subalocare bloc, fuzionare coadă sau împachetare coadă , unde ultimul bloc parțial de date din mai multe fișiere poate fi stocat într-un singur bloc „fragment” în loc de mai multe blocuri în mare parte goale ( Allen 2005 ).

Implementări

Furnizorii unor sisteme proprietare Unix, cum ar fi SunOS / Solaris , System V Release 4 , HP-UX și Tru64 UNIX și sisteme deschise derivate Unix, cum ar fi illumos , au adoptat UFS. Majoritatea au adaptat UFS la propriile utilizări, adăugând extensii proprietare care nu pot fi recunoscute de versiunile Unix ale altor furnizori. Mulți au continuat să folosească dimensiunea blocului original și lățimea câmpului de date ca UFS-ul original, astfel încât un anumit grad de compatibilitate a citirii rămâne pe toate platformele. În cel mai bun caz, compatibilitatea între implementări în ansamblu este neobișnuită.

Începând cu Solaris 7 , Sun Microsystems a inclus UFS Logging, care a adus jurnalul sistemului de fișiere în UFS, care este încă disponibil în versiunile actuale de Solaris și illumos. Solaris UFS are și extensii pentru fișiere mari și discuri mari și alte caracteristici.

În sistemele Unix 4.4BSD și BSD derivate din acesta, cum ar fi FreeBSD , NetBSD , OpenBSD și DragonFlyBSD , implementarea UFS1 și UFS2 este împărțită în două straturi: un strat superior care oferă structura directorului și acceptă metadatele (permisiuni, proprietate, etc.) în structura inodului și straturile inferioare care oferă containere de date implementate ca inoduri. Acest lucru a fost făcut pentru a sprijini atât FFS-ul tradițional, cât și sistemul de fișiere structurate în jurnal LFS cu cod partajat pentru funcții comune. Stratul superior se numește „UFS”, iar straturile inferioare se numesc „FFS” și „LFS”. În unele dintre aceste sisteme, termenul „FFS” este utilizat pentru combinația dintre stratul inferior FFS și stratul superior UFS, iar termenul „LFS” este utilizat pentru combinația stratului inferior LFS și stratul superior UFS.

Kirk McKusick a implementat realocarea blocurilor, o tehnică care reordonează blocurile din sistemul de fișiere chiar înainte de a se face scrierile pentru a reduce fragmentarea și a controla îmbătrânirea sistemului de fișiere. De asemenea, a implementat actualizări soft , un mecanism care menține coerența sistemului de fișiere fără a limita performanța în modul în care a funcționat modul tradițional de sincronizare. Acest lucru are ca efect secundar reducerea cerinței de verificare a sistemului de fișiere după un avarie sau întreruperea alimentării. Pentru a depăși problemele rămase după un eșec, a fost introdus un utilitar fsck de fundal.

În UFS2, Kirk McKusick și Poul-Henning Kamp au extins straturile FreeBSD FFS și UFS pentru a adăuga indicatori de blocare pe 64 de biți (permițând volumelor să crească până la 8 zebibiți ), blocuri de dimensiuni variabile (similar cu extensiile ), câmpuri de pavilion extinse, suplimentare timbre „naștere”, suport extins pentru atribute și ACL-uri POSIX1.e. UFS2 a devenit versiunea UFS implicită începând cu FreeBSD 5.0. FreeBSD a introdus, de asemenea, actualizări soft și posibilitatea de a face instantanee ale sistemului de fișiere atât pentru UFS1, cât și pentru UFS2. Acestea au fost portate de pe NetBSD, dar în cele din urmă actualizările soft (numite dependențe soft în NetBSD) au fost eliminate din NetBSD 6.0 în favoarea mecanismului de jurnalizare mai puțin complex al sistemului de fișiere numit WAPBL (denumit și logare), care a fost adăugat la FFS în NetBSD 5.0. OpenBSD a acceptat actualizări soft de la versiunea 2.9 și a primit suport UFS2 (FFS2) (fără ACL) de la versiunea 4.2. OpenBSD a făcut din UFS2 versiunea UFS implicită și va fi inclusă în versiunea 6.7. De la FreeBSD 7.0, UFS acceptă, de asemenea, jurnalizarea sistemului de fișiere utilizând furnizorul GEOM gjournal . FreeBSD 9.0 adaugă suport pentru jurnalizare ușoară pe lângă actualizări soft (SU + J), ceea ce reduce foarte mult nevoia de fsck de fundal și ACL-uri NFSv4.

FreeBSD, NetBSD, OpenBSD și DragonFly BSD includ, de asemenea, sistemul Dirhash , dezvoltat de Ian Dowse. Acest sistem menține un tabel hash în memorie pentru a accelera căutările de directoare. Dirhash ameliorează o serie de probleme de performanță asociate directoarelor mari din UFS.

Linux include o implementare UFS pentru compatibilitatea binară la nivel de citire cu alte Unixuri, dar din moment ce nu există o implementare standard pentru extensiile furnizorului la UFS, Linux nu are suport complet pentru scrierea în UFS. Sistemul de fișiere Linux ext2 nativ a fost inspirat de UFS1, dar nu acceptă fragmente și nu există planuri de implementare a actualizărilor soft. (În unele sisteme derivate de 4.4BSD, stratul UFS poate folosi un strat ext2 ca strat de container, la fel cum poate folosi FFS și LFS.)

NeXTStep , care a fost derivat din BSD, a folosit, de asemenea, o versiune a UFS. În Apple a lui Mac OS X , a fost disponibil ca alternativă la HFS + , sistemul de fișiere lor de proprietate. Cu toate acestea, începând cu Mac OS X Leopard , nu mai era posibil să instalați Mac OS X pe un volum formatat UFS. În plus, nu se pot actualiza versiuni mai vechi de Mac OS X instalate pe volume formatate UFS la Leopard; actualizarea necesită reformatarea volumului de pornire. A existat o limită de 4 GB pentru discuri formatate ca UFS în Mac OS X. Începând cu Mac OS X Lion , suportul UFS a fost complet abandonat.

Vezi si

• Compararea sistemelor de fișiere

Referințe

Citații

Bibliografie

linkuri externe

• Jeroen C. van Gelderen (23-04 2003). „Întrebări frecvente despre UFS2” . FreeBSD . Adus 08/04/2013 .
• "HOWTO pentru sisteme de fișiere: Alte sisteme de fișiere" . Proiectul de documentare Linux . 27.01.2007.
• Sistemul de fișiere Solaris UFS , consultați și [1]
• Format USF (sic) / UFS2
• Localitate și sistemul de fișiere rapid