ext3 - ext3

För genen, se EXT3 (gen) .
ext3
Utvecklare Stephen Tweedie
Fullständiga namn Tredje utökade filsystemet
Introducerad November 2001 med Linux 2.4.15
Partitionsidentifierare 0x83 ( MBR )
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 ( GPT )
Strukturer
Kataloginnehåll Tabell, hashat B-träd med dir_index aktiverat
Tilldelning av filer bitmapp (ledigt utrymme), tabell (metadata)
Dåliga block Tabell
Gränser
Max. volymstorlek 4 TiB - 32 TiB
Max. filstorlek 16 GiB - 2 TiB
Max. antal filer Variabel, tilldelad vid skapandetiden
Max. filnamn längd 255 byte
Tillåtna tecken i filnamn Alla byte utom NUL ('\ 0') och '/'
Funktioner
Datum registrerade modifiering (mtime), attributmodifiering (ctime), åtkomst (atime)
Datumintervall 14 december 1901 - 18 januari 2038
Datumupplösning 1 s
Attribut allow-undelete, append-only, h-tree (directory), immutable, journal, no-atime, no-dump, secure-delete, synchronous-write, top (directory)
Filsystemsbehörigheter Unix -behörigheter, ACL och godtyckliga säkerhetsattribut (Linux 2.6 och senare)
Genomskinlig kompression Nej
Transparent kryptering Nej (tillhandahålls på blockenhetsnivå)
Dataduplicering Nej
Övrig
Stöds operativsystem Linux , BSD , ReactOS , Windows (genom en IFS )

ext3 , eller tredje utökade filsystemet , är ett journalfört filsystem som vanligtvis används av Linux -kärnan . Det brukade vara standard filsystemet för många populära Linux-distributioner . Stephen Tweedie avslöjade först att han arbetade med att förlänga ext2 i Journaling the Linux ext2fs Filsystem i ett 1998 -papper, och senare i en kärnpostlista i februari 1999. Filsystemet slogs samman med mainline Linux -kärnan i november 2001 från 2.4.15 och framåt. Dess främsta fördel gentemot ext2 är journalföring , vilket förbättrar tillförlitligheten och eliminerar behovet av att kontrollera filsystemet efter en oren avstängning. Dess efterträdare är ext4 .

Fördelar

Prestandan (hastigheten) för ext3 är mindre attraktiv än konkurrerande Linux-filsystem, till exempel ext4, JFS , ReiserFS och XFS , men ext3 har en betydande fördel genom att det möjliggör uppgraderingar från ext2 utan att behöva säkerhetskopiera och återställa data . Benchmarks tyder på att ext3 också använder mindre CPU -effekt än ReiserFS och XFS. Det anses också säkrare än de andra Linux -filsystemen, på grund av dess relativa enkelhet och bredare testbas.

ext3 lägger till följande funktioner i ext2:

  • En journal
  • Tillväxt av filsystem online
  • HTree indexering för större kataloger

Utan dessa funktioner är alla ext3 -filsystem också ett giltigt ext2 -filsystem. Denna situation har gjort det möjligt för väl testade och mogna underhållssystem för filsystem för underhåll och reparation av ext2-filsystem att även användas med ext3 utan större förändringar. Ext2 och ext3 filsystem delar samma standard uppsättning verktyg, e2fsprogs , som inkluderar ett fsck -verktyg. Det nära förhållandet gör också konvertering mellan de två filsystemen (både framåt till ext3 och bakåt till ext2) enkel.

ext3 saknar "moderna" filsystemfunktioner, till exempel dynamisk inodallokering och omfattningar . Denna situation kan ibland vara en nackdel, men för återhämtning är det en betydande fördel. Filsystemets metadata finns alla på fasta, välkända platser, och datastrukturer har viss redundans. Vid betydande datakorruption kan ext2 eller ext3 vara återvinningsbara, medan ett trädbaserat filsystem kanske inte gör det.

Storleksgränser

Det maximala antalet block för ext3 är 2 32 . Storleken på ett block kan variera, vilket påverkar det maximala antalet filer och filsystemets maximala storlek:

Block storlek Maximal
filstorlek 		Maximal
filsystemstorlek
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 är 8 KiB -blockstorlek endast tillgänglig på arkitekturer som tillåter 8 KiB -sidor , till exempel Alpha .

Journaliseringsnivåer

Det finns tre nivåer av journalföring tillgängliga i Linux -implementeringen av ext3:

Journal (lägsta risk)
Både metadata och filinnehåll skrivs till journalen innan de ansluts till huvudfilsystemet. Eftersom journalen är relativt kontinuerlig på hårddisk kan detta förbättra prestanda om journalen har tillräckligt med utrymme. I andra fall blir prestanda sämre, eftersom data måste skrivas två gånger - en gång till journalen och en gång till huvuddelen av filsystemet.
Beställt (medelstor risk)
Endast metadata journalförs; filinnehåll är inte det, men det är garanterat att filinnehållet skrivs till hårddisken innan associerade metadata markeras som åtaganden i journalen. Detta är standard på många Linux -distributioner. Om det uppstår strömavbrott eller kärnpanik medan en fil skrivs eller läggs till, kommer journal att indikera att den nya filen eller de bifogade uppgifterna inte har "begåtts", så den kommer att rensas genom saneringsprocessen. (Således läggs till och nya filer har samma integritetsskyddsnivå som nivån "journalförd".) Filer som skrivs över kan dock skadas eftersom originalversionen av filen inte lagras. Således är det möjligt att hamna med en fil i ett mellanliggande tillstånd mellan nytt och gammalt, utan tillräckligt med information för att återställa antingen den ena eller den andra (de nya uppgifterna kom aldrig helt till hårddisken och de gamla uppgifterna lagras inte någonstans). Ännu värre kan mellantillståndet varva gamla och nya data, eftersom skrivordningens ordning överlämnas till hårddiskens maskinvara.
Writeback (högsta risk)
Endast metadata journalförs; filinnehållet är inte. Innehållet kan skrivas före eller efter att tidskriften har uppdaterats. Som ett resultat kan filer som ändrats precis innan en krasch skadas. Till exempel kan en fil som bifogas markeras i journalen som större än den faktiskt är, vilket kan orsaka skräp i slutet. Äldre versioner av filer kan också visas oväntat efter en journalåterställning. Bristen på synkronisering mellan data och journal är snabbare i många fall. JFS använder denna nivå av journalföring, men ser till att eventuellt "skräp" på grund av oskriven data nollställs vid omstart. XFS använder också denna form av journalföring.

I alla tre lägen säkerställs filsystemets interna struktur att vara konsekvent även efter en krasch. I vilket fall som helst påverkas endast datainnehållet i filer eller kataloger som ändrades när systemet kraschade; resten kommer att vara intakt efter återhämtningen.

Nackdelar

Funktionalitet

Eftersom ext3 syftar till att vara bakåtkompatibel med det tidigare ext2, liknar många av disk-strukturerna de på ext2. Följaktligen saknar ext3 senaste funktioner, till exempel omfattningar , dynamisk tilldelning av inoder och blockundertilldelning . En katalog kan ha högst 31998 underkataloger , eftersom en inod kan ha högst 32 000 länkar (varje direkt underkatalog ökar sin överordnade mapps inodlänkräknare i referensen "..").

ext3, som de flesta nuvarande Linux -filsystem, bör inte fsck -ed medan filsystemet är monterat för skrivning. Att försöka kontrollera ett filsystem som redan är monterat i läs-/skrivläge kommer (mycket troligt) att upptäcka inkonsekvenser i filsystemets metadata. När filsystemets metadata ändras och fsck tillämpar ändringar i ett försök att föra de "inkonsekventa" metadata till ett "konsekvent" tillstånd, kommer försöket att "fixa" inkonsekvenserna att skada filsystemet.

Defragmentering

Det finns inget online ext3 -defragmenteringsverktyg som fungerar på filsystemnivå. Det finns en offline ext2 defragmenter, e2defrag. Kan e2defragdock förstöra data, beroende på funktionsbitarna som är påslagna i filsystemet; den vet inte hur man hanterar många av de nyare ext3 -funktionerna.

Det finns användarutrymme defragmenteringsverktyg, som Shake och defragmentering. Shake fungerar genom att allokera utrymme för hela filen som en operation, vilket i allmänhet kommer att leda till att allokatorn hittar sammanhängande diskutrymme. Om det finns filer som används samtidigt, kommer Shake att försöka skriva dem bredvid varandra. Defrag fungerar genom att kopiera varje fil över sig själv. Denna strategi fungerar dock bara om filsystemet har tillräckligt med ledigt utrymme. Ett riktigt defragmenteringsverktyg finns inte för ext3.

Men som Linux System Administrator Guide säger, "Moderna Linux -filsystem (er) håller fragmentering till ett minimum genom att hålla alla block i en fil nära varandra, även om de inte kan lagras i på varandra följande sektorer. Vissa filsystem, som ext3, fördela effektivt det kostnadsfria blocket som ligger närmast andra block i en fil. Därför är det inte nödvändigt att oroa sig för fragmentering i ett Linux -system. "

Medan ext3 är resistent mot filfragmentering kan ext3 bli fragmenterad över tid eller för specifika användningsmönster, som att långsamt skriva stora filer. Följaktligen har ext4 (efterföljaren till ext3) ett online filsystemdefragmenteringsverktyg e4defrag och stöder för närvarande extents (sammanhängande filregioner).

Återställ

ext3 stöder inte återställning av raderade filer. Ext3 -drivrutinen raderar aktivt filer genom att torka filinoder av säkerhetsskäl.

Det finns fortfarande flera tekniker och lite gratis och egenutvecklad programvara för återställning av raderade eller förlorade filer med hjälp av filsystemets journalanalys; de garanterar dock ingen specifik filåterställning.

Kompression

e3compr är en inofficiell patch för ext3 som gör transparent komprimering . Det är en direktport för e2compr och behöver fortfarande vidareutvecklas. Det kompilerar och startar bra med uppströms kärnor, men journalföring är inte implementerat ännu.

Brist på stöd för ögonblicksbilder

Till skillnad från ett antal moderna filsystem har ext3 inte inbyggt stöd för ögonblicksbilder , möjligheten att snabbt fånga tillståndet i filsystemet vid godtyckliga tider. Istället förlitar det sig på mindre utrymmeeffektiva ögonblicksbilder på volymnivå som tillhandahålls av Linux LVM . Det Next3 filsystemet är en modifierad version av ext3 som erbjuder snapshots stöd behåller kompatibilitet med ext3 på skivformat ännu.

Ingen kontrollsummning i journal

ext3 gör inte kontrollsummning när du skriver till tidningen. På en lagringsenhet med extra cache, om barriär = 1 inte är aktiverat som ett monteringsalternativ (in /etc /fstab ), och om hårdvaran gör skrivbuffert som inte är i ordning, riskerar man allvarlig filsystemskada under en krash. Detta beror på att lagringsenheter med skrivcachar rapporterar till systemet att data har skrivits helt, även om det skrevs till (flyktig) cache.

Om hårddiskskrivningar görs ur ordning (på grund av moderna hårddiskar som cachar skriver för att amortera skrivhastigheter) är det troligt att man kommer att skriva ett bindningsblock för en transaktion innan de andra relevanta blocken skrivs. Om ett strömavbrott eller en oåterkallelig krasch skulle inträffa innan de andra blocken skrivs, måste systemet startas om. Vid omstart kommer filsystemet att spela om loggen som vanligt och spela om "vinnarna" (transaktioner med ett åtagandeblock, inklusive den ogiltiga transaktionen ovan, som råkade märkas med ett giltigt åtagandeblock). Den ofärdiga diskskrivningen ovan fortsätter således, men med korrupta journaldata. Filsystemet kommer därmed av misstag att skriva över normal data med korrupta data medan du spelar upp journalen igen. Om kontrollsummor hade använts, där blocken av den "falska vinnaren" -transaktionen var märkta med en ömsesidig kontrollsumma, kunde filsystemet ha vetat bättre och inte spelat om den korrupta informationen på disken. Journalkontrollsummning har lagts till i ext4.

Filsystem som går igenom enhetsmappningsgränssnittet (inklusive RAID- och LVM -implementeringar av programvara ) kanske inte stöder hinder och kommer att utfärda en varning om det monteringsalternativet används. Det finns också några skivor som inte korrekt implementerar förlängningen av skrivcache -spolning som är nödvändig för att hinder ska fungera, vilket orsakar en liknande varning. I dessa situationer, där hinder inte stöds eller är praktiska, är tillförlitlig skrivordning möjlig genom att stänga av diskens skrivcache och använda data=journalmonteringsalternativet. Stänga av hårddiskens cacheminne kan krävas även när hinder finns tillgängliga.

Program som databaser förväntar sig ett samtal till fsync () för att spola väntande skrivningar till hårddisken, och barriärimplementeringen rensar inte alltid enhetens skrivcache som svar på det samtalet. Det finns också ett potentiellt problem med barriärimplementeringen relaterad till felhantering under händelser, till exempel ett enhetsfel. Det är också känt att vissa virtualiseringsteknologier ibland inte vidarebefordrar fsync- eller spolkommandon till de underliggande enheterna (filer, volymer, disk) från ett gästoperativsystem. På samma sätt implementerar vissa hårddiskar eller styrenheter cachespolning felaktigt eller inte alls, men annonserar fortfarande att den stöds och ger inga fel när den används. Det finns så många sätt att hantera fsync och skriva cachehantering felaktigt, det är säkrare att anta att cachespolning inte fungerar om det inte uttryckligen testas, oavsett hur tillförlitliga enskilda komponenter tros vara.

Nästan utrotning på grund av datumstämpelbegränsning

Ext3 lagrar datum som Unix -tid med fyra byte i filhuvudet. 32 bitar ger inte tillräckligt med utrymme för att fortsätta bearbeta filer efter den 18 januari 2038 - året 2038 -problemet . Detta "Geek's Millennium" förväntas orsaka omfattande störningar om det inte hanteras i tid.

ext4

Image
fsck tidsberoende på inodtal (ext3 vs. ext4)
Huvudartikel: ext4

Den 28 juni 2006 meddelade Theodore Ts'o , huvudutvecklaren av ext3, en förbättrad version, kallad ext4. Den 11 oktober 2008 slogs de patchar som markerar ext4 som stabil kod samman i Linux 2.6.28 källkodslager, vilket markerar slutet på utvecklingsfasen och rekommenderar att den antas. Under 2008 uppgav Ts'o att även om ext4 har förbättrade funktioner som att vara mycket snabbare än ext3, är det inte ett stort framsteg, det använder gammal teknik och är ett stopp. Ts'o anser att Btrfs är den bättre riktningen, eftersom "den erbjuder förbättringar av skalbarhet, tillförlitlighet och enkel hantering". Btrfs har också "ett antal samma designidéer som reiser3 / 4 hade".

Se även

Referenser

externa länkar