ext3 - ext3

For genet, se EXT3 (gen) .
ext3
Udvikler (er) Stephen Tweedie
Fulde navn Tredje udvidede filsystem
Introduceret November 2001 med Linux 2.4.15
Partitionsidentifikator 0x83 ( MBR )
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 ( GPT )
Strukturer
Telefonbogens indhold Tabel, hash- B-træ med dir_index aktiveret
Tildeling af filer bitmap (ledig plads), tabel (metadata)
Dårlige blokke Bord
Grænser
Maks. volumen størrelse 4 TiB - 32 TiB
Maks. filstørrelse 16 GiB - 2 TiB
Maks. antal filer Variabel, tildelt på oprettelsestidspunktet
Maks. filnavn længde 255 bytes
Tilladte tegn i filnavne Alle bytes undtagen NUL ('\ 0') og '/'
Funktioner
Datoer registreret ændring (mtime), attributmodifikation (ctime), adgang (atime)
Datointerval 14. december 1901 - 18. januar 2038
Datoopløsning 1 s
Egenskaber tillad-sletning, kun tilføjelse, h-tree (bibliotek), uforanderlig, journal, ingen-atime, ingen-dump, sikker-slet, synkron-skriv, top (bibliotek)
Tilladelser til filsystem Unix -tilladelser, ACL'er og vilkårlige sikkerhedsattributter (Linux 2.6 og nyere)
Gennemsigtig kompression Ingen
Gennemsigtig kryptering Nej (leveres på blokenhedsniveau)
Dataduplikering Ingen
Andet
Understøttede operativsystemer Linux , BSD , ReactOS , Windows (gennem en IFS )

ext3 , eller tredje udvidede filsystem , er et journaliseret filsystem, der almindeligvis bruges af Linux -kernen . Det plejede at være standard filsystemet for mange populære Linux-distributioner . Stephen Tweedie afslørede først, at han arbejdede på at udvide ext2 i Journaling af Linux ext2fs -filsystemet i et papir fra 1998 og senere i en postning af kernel -mailingliste i februar 1999. Filsystemet blev fusioneret med mainline Linux -kernen i november 2001 fra 2.4.15 og fremefter. Dens største fordel i forhold til ext2 er journalisering , hvilket forbedrer pålideligheden og eliminerer behovet for at kontrollere filsystemet efter en uren nedlukning. Dens efterfølger er ext4 .

Fordele

Ydelsen (hastigheden) for ext3 er mindre attraktiv end konkurrerende Linux-filsystemer, såsom ext4, JFS , ReiserFS og XFS , men ext3 har en betydelig fordel ved, at den tillader opgraderinger på stedet fra ext2 uden at skulle sikkerhedskopiere og gendanne data . Benchmarks tyder på, at ext3 også bruger mindre CPU -strøm end ReiserFS og XFS. Det betragtes også som sikrere end de andre Linux -filsystemer på grund af dets relative enkelhed og bredere testbase.

ext3 tilføjer følgende funktioner til ext2:

Uden disse funktioner er ethvert ext3 -filsystem også et gyldigt ext2 -filsystem. Denne situation har gjort det muligt for velprøvede og modne værktøjer til vedligeholdelse af filsystemer til vedligeholdelse og reparation af ext2-filsystemer også at blive brugt med ext3 uden større ændringer. Ext2- og ext3 -filsystemerne deler det samme standardsæt med hjælpeprogrammer, e2fsprogs , som inkluderer et fsck -værktøj. Det tætte forhold gør også konvertering mellem de to filsystemer (både frem til ext3 og baglæns til ext2) ligetil.

ext3 mangler "moderne" filsystemfunktioner, såsom dynamisk inodeallokering og omfang . Denne situation kan undertiden være en ulempe, men for genoprettelsesevnen er det en betydelig fordel. Filsystemets metadata er alle på faste, velkendte steder, og datastrukturer har en vis redundans. Ved betydelig datakorruption kan ext2 eller ext3 muligvis genoprettes, mens et træbaseret filsystem ikke gør det.

Størrelsesgrænser

Det maksimale antal blokke for ext3 er 2 32 . Størrelsen på en blok kan variere, hvilket påvirker det maksimale antal filer og filsystemets maksimale størrelse:

Blokstørrelse Maksimal
filstørrelse 		Maksimal
filsystemstørrelse
1 KiB 16 GiB 2 TiB
2 KiB 256 GiB 8 TiB
4 KiB 2 TiB 16 TiB
8 KiB 2 TiB 32 TiB
  1. ^ I Linux er 8 KiB -blokstørrelse kun tilgængelig på arkitekturer, der tillader 8 KiB -sider , f.eks. Alpha .

Journaliseringsniveauer

Der er tre journalingniveauer tilgængelige i Linux -implementeringen af ​​ext3:

Journal (laveste risiko)
Både metadata og filindhold skrives til journalen, før de bliver forpligtet til hovedfilsystemet. Fordi journalen er relativt kontinuerlig på disk, kan dette forbedre ydeevnen, hvis journalen har nok plads. I andre tilfælde bliver ydelsen dårligere, fordi dataene skal skrives to gange - en gang til journalen og en gang til hoveddelen af ​​filsystemet.
Bestilt (medium risiko)
Kun metadata journaliseres; filindhold er ikke, men det er garanteret, at filindholdet skrives til disken, før tilhørende metadata markeres som forpligtet i journalen. Dette er standard på mange Linux -distributioner. Hvis der er strømafbrydelse eller kernepanik, mens en fil skrives eller tilføjes, angiver journalen, at den nye fil eller de vedhæftede data ikke er blevet "begået", så den bliver renset ved oprydningsprocessen. (Således tilføjes og nye filer har samme grad af integritetsbeskyttelse som niveauet "journaliseret".) Filer, der overskrives, kan imidlertid blive ødelagt, fordi den originale version af filen ikke er gemt. Således er det muligt at ende med en fil i en mellemliggende tilstand mellem ny og gammel, uden nok information til at gendanne enten den ene eller den anden (de nye data kom aldrig helt til disken, og de gamle data gemmes ikke nogen steder). Endnu værre, den mellemliggende tilstand kan sprede gamle og nye data, fordi rækkefølgen af ​​skrivningen er overladt til diskens hardware.
Writeback (højeste risiko)
Kun metadata journaliseres; filindhold er ikke. Indholdet kan blive skrevet før eller efter at journalen er opdateret. Som et resultat kan filer, der er ændret lige før et nedbrud, blive ødelagt. For eksempel kan en fil, der tilføjes, blive markeret i journalen som større end den faktisk er, hvilket forårsager affald i slutningen. Ældre versioner af filer kan også vises uventet efter en journalgendannelse. Manglen på synkronisering mellem data og journal er hurtigere i mange tilfælde. JFS bruger dette journalføringsniveau, men sikrer, at alt "skrald" på grund af uskrevne data nulstilles ved genstart. XFS bruger også denne form for journalføring.

I alle tre tilstande er filsystemets interne struktur sikret at være konsekvent, selv efter et nedbrud. Under alle omstændigheder påvirkes kun dataindholdet i filer eller mapper, der blev ændret, da systemet styrtede ned; resten vil være intakt efter genopretning.

Ulemper

Funktionalitet

Fordi ext3 sigter mod at være bagudkompatibel med det tidligere ext2, ligner mange af diskens strukturer dem på ext2. Derfor mangler ext3 nylige funktioner, såsom omfang , dynamisk allokering af inoder og blokaltildeling . Et bibliotek kan højst have 31998 underkataloger , fordi en inode højst kan have 32.000 links (hver direkte underkatalog øger deres overordnede mappe inode link tæller i ".." referencen).

ext3, ligesom de fleste nuværende Linux -filsystemer, bør ikke fsck -ed, mens filsystemet er monteret til skrivning. Forsøg på at kontrollere et filsystem, der allerede er monteret i læse/skrive -tilstand, vil (meget sandsynligt) opdage inkonsekvenser i filsystemets metadata. Hvor filsystemmetadata ændrer sig, og fsck anvender ændringer i et forsøg på at bringe de "inkonsekvente" metadata i en "konsistent" tilstand, vil forsøget på at "rette" inkonsekvenserne ødelægge filsystemet.

Defragmentering

Der er ikke noget online ext3 -defragmenteringsværktøj , der fungerer på filsystemniveau. Der er en offline ext2 defragmenter, e2defrag. Dog e2defragkan det ødelægge data afhængigt af funktionsbitene, der er tændt i filsystemet; den ved ikke, hvordan den skal håndtere mange af de nyere ext3 -funktioner.

Der er defragmenteringsværktøjer til brugerrum, som Shake og defragmentering. Shake virker ved at allokere plads til hele filen som en operation, hvilket generelt får tildeleren til at finde sammenhængende diskplads. Hvis der er filer, der bruges på samme tid, vil Shake forsøge at skrive dem ved siden af ​​hinanden. Defrag fungerer ved at kopiere hver fil over sig selv. Denne strategi fungerer dog kun, hvis filsystemet har nok ledig plads. Et ægte defragmenteringsværktøj findes ikke for ext3.

Men som det står i Linux System Administrator Guide, "Moderne Linux -filsystem (er) holder fragmentering på et minimum ved at holde alle blokke i en fil tæt sammen, selvom de ikke kan gemmes i på hinanden følgende sektorer. Nogle filsystemer, f.eks. Ext3, tildel effektivt den gratis blok, der er tættest på andre blokke i en fil. Derfor er det ikke nødvendigt at bekymre sig om fragmentering i et Linux -system. "

Selvom ext3 er modstandsdygtig over for filfragmentering, kan ext3 blive fragmenteret over tid eller til specifikke brugsmønstre, som langsomt at skrive store filer. Derfor har ext4 (efterfølgeren til ext3) et online filsystemdefragmenteringsværktøj e4defrag og understøtter i øjeblikket extents (sammenhængende filområder ).

Fortryd sletning

ext3 understøtter ikke gendannelse af slettede filer. Ext3 -driveren sletter aktivt filer ved at tørre filinoder af sikkerhedsmæssige årsager til crash.

Der er stadig flere teknikker og nogle gratis og proprietære software til gendannelse af slettede eller tabte filer ved hjælp af filsystem journal analyse; de garanterer dog ikke nogen specifik filgendannelse.

Kompression

e3compr er en uofficiel patch til ext3, der laver gennemsigtig komprimering . Det er en direkte port til e2compr og har stadig brug for yderligere udvikling. Det kompilerer og starter godt med opstrøms kerner, men journalisering er ikke implementeret endnu.

Mangel på snapshots support

I modsætning til en række moderne filsystemer har ext3 ikke native support til snapshots , evnen til hurtigt at fange filsystemets tilstand på vilkårlige tidspunkter. I stedet er den afhængig af mindre pladsbesparende snapshots på volumeniveau leveret af Linux LVM . Det Next3 filsystemet er en modificeret udgave af ext3 som tilbud snapshots støtte, men bevarer kompatibilitet med ext3 på disk-format.

Ingen kontrolsummering i journal

ext3 foretager ikke kontrolsummering, når der skrives til journalen. På en lagerenhed med ekstra cache, hvis barriere = 1 ikke er aktiveret som en monteringsindstilling (i /etc /fstab ), og hvis hardwaren laver skrivebuffer uden for ordren, risikerer man alvorlig filsystemkorruption under et styrt. Dette skyldes, at lagerenheder med skrive -caches rapporterer til systemet, at dataene er blevet fuldstændigt skrevet, selvom de blev skrevet til den (flygtige) cache.

Hvis harddiskskrivninger udføres uden for ordre (på grund af moderne harddiske cacher skriver for at amortisere skrivehastigheder), er det sandsynligt, at man vil skrive en commit-blok af en transaktion, før de andre relevante blokke skrives. Hvis der skulle opstå et strømsvigt eller et uopretteligt nedbrud, før de andre blokke bliver skrevet, skal systemet genstartes. Ved genstart vil filsystemet afspille loggen som normalt og afspille "vindere" (transaktioner med en forpligtelsesblok, herunder den ugyldige transaktion ovenfor, der tilfældigvis blev mærket med en gyldig forpligtelsesblok). Den ufærdige diskskrivning ovenfor fortsætter således, men ved hjælp af korrupte journaldata. Filsystemet vil dermed fejlagtigt overskrive normale data med korrupte data under afspilning af journalen. Hvis kontrolsummer var blevet brugt, hvor blokkene i den "falske vinder" -transaktion blev mærket med en gensidig kontrolsum, kunne filsystemet have vidst bedre og ikke afspille de korrupte data på disken. Journal checksumming er blevet tilføjet til ext4.

Filsystemer, der går gennem enhedens mapper -grænseflade (inklusive software RAID og LVM -implementeringer) understøtter muligvis ikke barrierer og udsender en advarsel, hvis denne monteringsindstilling bruges. Der er også nogle diske, der ikke korrekt implementerer skrive -cache -skylleudvidelsen, der er nødvendig for barrierer for at fungere, hvilket forårsager en lignende advarsel. I disse situationer, hvor barrierer ikke understøttes eller er praktisk, er pålidelig skrivebestilling mulig ved at slukke diskens skrive -cache og bruge data=journalmonteringsindstillingen. Det kan være nødvendigt at deaktivere diskens skrive -cache, selvom der er tilgængelige barrierer.

Applikationer som databaser forventer et opkald til fsync () for at skylle afventende skrivninger til disk, og barriereimplementeringen rydder ikke altid drevets cache som svar på det opkald. Der er også et potentielt problem med barriereimplementeringen i forbindelse med fejlhåndtering under hændelser, f.eks. Et drevfejl. Det er også kendt, at nogle virtualiseringsteknologier nogle gange ikke korrekt videresender fsync eller skyller kommandoer til de underliggende enheder (filer, diskenheder, disk) fra et gæstoperativsystem. På samme måde implementerer nogle harddiske eller controllere cacheskylning forkert eller slet ikke, men reklamerer stadig for, at den understøttes, og returnerer ikke nogen fejl, når den bruges. Der er så mange måder at håndtere fsync og skrive cachehåndtering forkert på, det er mere sikkert at antage, at cacheskylning ikke virker, medmindre det eksplicit testes, uanset hvor pålidelige individuelle komponenter menes at være.

Nærtid udryddelse på grund af dato-stempel begrænsning

Ext3 gemmer datoer som Unix -tid ved hjælp af fire bytes i filoverskriften. 32 bits giver ikke nok plads til at fortsætte behandlingen af ​​filer efter den 18. januar 2038 - år 2038 -problemet . Dette "Geek's Millennium" forventes at forårsage omfattende forstyrrelser, hvis det ikke behandles rettidigt.

ext4

fsck tidsafhængighed af inode tæller (ext3 vs. ext4)
Hovedartikel: ext4

Den 28. juni 2006 annoncerede Theodore Ts'o , hovedudvikleren af ​​ext3, en forbedret version, kaldet ext4. Den 11. oktober 2008 blev de patches, der markerer ext4 som stabil kode, fusioneret i Linux 2.6.28 kildekodeopbevaringsstederne, hvilket markerede afslutningen på udviklingsfasen og anbefalede dens vedtagelse. I 2008 erklærede Ts'o, at selvom ext4 har forbedrede funktioner, såsom at være meget hurtigere end ext3, er det ikke et stort fremskridt, det bruger gammel teknologi og er et stop-gap; Ts'o mener, at Btrfs er den bedre retning, fordi "den tilbyder forbedringer i skalerbarhed, pålidelighed og brugervenlighed". Btrfs har også "en række af de samme designideer, som rejser3 / 4 havde".

Se også

Referencer

eksterne links