Ext2 filsystem i Linux. Hvordan få tilgang til Ext2, Ext3, Ext4 filsystemer i Windows-miljø Ext2 filsystem

Hvordan gjøre det mulig å få tilgang til en diskpartisjon eller flyttbare medier med filsystemer i et Windows-miljø Utv2/3/4 ? Hvis det for eksempel også er et ekstra system på datamaskinen Linux. Og du må jobbe med dataene fra miljøet Windows. Eller et annet eksempel - når virtuelle disker er montert inne i Windows med installert virtuelle maskiner systemer Linux eller Android. Med Ext2/3/ 4 Windows kan ikke fungere naturlig; det trenger tredjepartsverktøy for dette. Hva slags midler er dette? La oss se på dem nedenfor.

***
De tre første verktøyene vil gjøre det mulig å kun lese informasjonsenheter fra Utv2/3/4. Den nyeste løsningen lar deg både lese og skrive data. Alle verktøyene som er omtalt nedenfor er gratis.

1. DiskInternals Linux Reader

Et enkelt program er en primitiv filbehandler, laget som en standard Windows Explorer, med støtte for filsystemer Ext 2/3/4 , Reiser4 , HFS , UFS2. I programvinduet vil vi se partisjoner og enheter med Linux eller Android.

For å kopiere, må du velge en mappe eller fil, trykk på knappen "Lagre".

Angi deretter kopibanen.

2. Plugin for Total Commander DiskInternals Reader

Fans av det populære kan trekke ut data Linux eller Android inne i Windows ved å bruke denne filbehandleren. Men først installer en spesiell plugin i den. En av disse pluginene er at den kan koble til og lese informasjonsenheter formatert i Utv2/3/4 , Fett/exFAT , HFS/HFS+ , ReiserFS. Last ned plugin, pakk ut arkivet inni , bekreft installasjonen.

La oss lansere (viktig) på vegne av administrator. La oss gå til delen. Klikk.

Her, sammen med andre diskpartisjoner og media, den med Utv2/3/4 .

Data kopieres tradisjonelt måte - ved å trykke F5 på det andre panelet.

3. Plugin for Total Commander ext4tc

Et forenklet alternativ til den forrige løsningen - ext4tc, en annen plugin for . Den kan koble til leseinformasjonsenheter som kun er formatert i Utv2/3/4. Last ned plugin-en, pakk ut arkivet i filbehandleren og start installasjonen.

La oss lansere (viktig) på vegne av administrator. Klikk. La oss gå til .

Hvis du trenger å kopiere data, bruk den vanlige metoden med F5-tasten.

4. Ext2Fsd-støttedriver

Program Ext2Fsd– dette er sjåføren Utv2/3/4, implementerer den støtte for disse filsystemene på operativsystemnivå. Du kan arbeide med diskpartisjoner og stasjoner formatert med disse filsystemene som med vanlige Windows-støttede medieenheter i et Utforsker-vindu eller tredjeparts programmer. Driveren lar deg både lese og skrive data.

Last ned den nyeste versjonen Ext2Fsd.

Under installasjonen aktiverer vi (hvis for langsiktig arbeid) tre foreslåtte avmerkingsbokser:

1 — Autokjør av driver med Windows;
2 - Opptaksstøtte for Ext2;
3 - Formateringsstøtte for Ext3.

På pre-finishing-stadiet aktiverer vi alternativet for å starte driver manager-vinduet - - sammen med å tildele informasjon til enheter fra Utv2/3/4 stasjonsbokstaver.

I vinduet som åpnes Vi vil se media med brevet allerede tildelt. For eksempel, i vårt tilfelle, en transportør med Ext4 det første gratisbrevet er gitt F.

Nå kan vi jobbe med disken F i Utforsker-vinduet.

Tilordne et brev til nye tilkoblede enheter med Utv2/3/4 kan gjøres ved å bruke kontekstmenyen som vises på hver av de som vises i vinduet enheter. Men bare ved å tilordne en stasjonsbokstav, vil en slik enhet ikke vises etter start Windows på nytt, er denne løsningen kun for én datamaskinøkt. For å lage en ny enhet med Utv2/3/4 permanent synlig i Windows-miljøet, må du dobbeltklikke på det for å åpne konfigurasjonsvinduet og angi permanente tilkoblingsparametere. I den andre kolonnen trenger du:

For flyttbare medier, aktiver avmerkingsboksen angitt med nummer 1 i skjermbildet og spesifiser stasjonsbokstaven;
For interne disker og partisjoner, aktiver avmerkingsboksen angitt i skjermbildet nedenfor med tallet 2, og spesifiser også stasjonsbokstaven.

14 jun

Filsystemer ext2, ext3, XFS, ReiserFS, NTFS

Filsystem- dette er rekkefølgen som bestemmer måten å organisere, lagre og navngi data på alle elektroniske lagringsmedier i datamaskiner.

Variasjonen av filsystemer forklares av det faktum at hver ble oppfunnet for sitt eget spesifikke sett med oppgaver. Noen skriver veldig raskt små filer (f.eks. opptil 1 GB), men samhandler samtidig dårlig med store filer eller fungerer ikke med dem i det hele tatt. Noen er gode fra et sikkerhetssynspunkt, andre fra et lese/skrivehastighetssynspunkt. Hvert filsystem har sine egne fordeler, ulemper, sårbarheter og særegne muligheter.

I Linux De mest brukte typene filsystemer er:

  1. ext2- står for Andre utvidede filsystem(andre utvidet filsystem). Utviklet av Remy Card i 1993 som et filsystem for Linux-kjernen, fra 1993 til 2001 var det hovedfilsystemet Linux.
    Fordelen er høy lese-/skrivehastighet.
    Den største ulempen med systemet ext2 er at den ikke er journalført, men nettopp på grunn av dette har den god ytelse ( hogst er en journalføringsprosess som lagrer en liste over endringer som bidrar til å opprettholde integriteten til filsystemet under forskjellige systemfeil);
  2. ext3- står for Tredje utvidet filsystem(tredje versjon av det utvidede filsystemet). Utviklet av Stephen Tweedy i 2001, fortsatt brukt i dag i distribusjoner Linux. Ble født som en forbedret ext2.
    Fordelen med dette systemet er at det er journalført, det vil si at dets pålitelighet øker betydelig i forhold til ext2.
    Ulempen er litt lavere ytelse og lese/skrivehastighet.
  3. XFS— Utviklet av selskapet Silisium grafikk i 1993, ble lagt til kjernen Linux som et filsystem i 2002 på tvers av hele familien av distribusjoner Linux, for øyeblikket brukt som "innfødt" i distribusjonen Rød hatt.
    Fordelen er tilstedeværelsen av metadatalogging, høy driftsstabilitet, fordelingen av input/output-strømmer i grupper støttes, høye lese-/skrivehastigheter, det er mulig å defragmentere selv når partisjonen er montert, og du kan øke størrelsen på filsystemet. Fungerer mest effektivt med store filer.
    Ulempen er at partisjonsstørrelsen ikke kan reduseres, metadatabehandlingsprosessen er ikke så rask, og den fungerer merkbart tregere med små filer enn andre typer filsystemer.
  4. ReiserFS- utviklet av selskapet Namesys under ledelse av Hans Reiser i 2001. Kun brukt på operativsystemer Linux. Det var det første journalførte filsystemet som ble tatt i bruk i kjernen.
    Fordelen med dette filsystemet er at det fungerer veldig raskt med små filer (lese-/skrivehastigheten er høyere enn ext4), støtter logging.
    Ulempen er at utviklingen har avtatt merkbart på grunn av arrestasjonen av lederen, Hans Reiser, og det er ingen bakgrunnskryptering.
  5. NTFS- står for nytt teknologi filsystem(ny teknologi filsystem). Utviklet i juli 1993 av selskapet Microsoft. Mye brukt i ulike operativsystemer, samt i ulike lagringsmedier.
    Fordelen er den innebygde muligheten til å begrense tilgang til data for ulike brukere, samt tildele begrensninger på maksimalt volum diskplass, bruk av et journalsystem, høyhastighets lesing/skriving av små filer.
    Ulempen er at stabil drift krever en stor mengde PC-RAM, den fungerer sakte med store filer, og lengden på banen til filene er begrenset (32 767 Unicode-tegn).

På denne enkle måten fant vi ut "filsystemer ext2, ext3, XFS, ReiserFS, NTFS«!

Filsystem(engelsk filsystem) - en ordre som bestemmer måten å organisere, lagre og navngi data på informasjonslagringsmedier til IT-utstyr (ved bruk av bærbare flash-minnekort for gjentatt opptak og lagring av informasjon i bærbare elektroniske enheter: digitale kameraer, mobiltelefoner etc.) og datautstyr. Den definerer formatet på innholdet og fysisk lagring av informasjon, som vanligvis er gruppert i form av filer. Et spesifikt filsystem bestemmer størrelsen på filnavnet (mappen), maksimal mulig fil- og partisjonsstørrelse og et sett med filattributter. Noen filsystemer tilbyr tjenestefunksjoner, for eksempel tilgangskontroll eller filkryptering.

Filsystemoppgaver

Hovedfunksjonene til ethvert filsystem er rettet mot å løse følgende problemer:

filnavn;

programvaregrensesnitt for arbeid med filer for applikasjoner;

kartlegge den logiske modellen til filsystemet til den fysiske organiseringen av datalagringen;
organisere filsystemets motstandskraft mot strømbrudd, maskinvare- og programvarefeil;

I flerbrukersystemer vises en annen oppgave: å beskytte filene til en bruker mot uautorisert tilgang fra en annen bruker, samt sikre samarbeid med filer, for eksempel når en av brukerne åpner en fil, for andre vil den samme filen være midlertidig tilgjengelig i skrivebeskyttet modus.

Et filsystem er den grunnleggende strukturen en datamaskin bruker for å organisere informasjon på harddisken. Når du installerer en ny harddisk den må partisjoneres og formateres for et spesifikt filsystem, hvoretter data og programmer kan lagres på den. Det er tre mulige filsystemalternativer i Windows: NTFS, FAT32 og det sjelden brukte eldre FAT-systemet (også kjent som FAT16).

NTFS er det foretrukne filsystemet for denne versjonen av Windows. Det har mange fordeler i forhold til det eldre FAT32-systemet; Noen av dem er listet opp nedenfor.

Muligheten til å gjenopprette automatisk fra enkelte diskfeil (FAT32 har ikke denne muligheten).
Forbedret støtte for store harddisker.
Høyere grad av sikkerhet. Du kan bruke tillatelser og kryptering for å nekte brukertilgang til visse filer.

FAT32-filsystemet og det sjelden brukte FAT-systemet ble brukt tidligere Windows-versjoner, inkludert Windows 95, Windows 98 og Windows Millenium Edition. FAT32-filsystemet gir ikke sikkerhetsnivået som tilbys av NTFS, så hvis datamaskinen din har en partisjon eller et volum formatert som FAT32, er filene på den partisjonen synlige for alle som har tilgang til datamaskinen. FAT32-filsystemet har også filstørrelsesbegrensninger. I denne versjonen av Windows er det ikke mulig å lage en FAT32-partisjon som er større enn 32 GB. I tillegg kan ikke en FAT32-partisjon inneholde en fil som er større enn 4 GB.

Hovedårsaken til å bruke et FAT32-system er at datamaskinen vil kunne kjøre enten Windows 95, Windows 98 eller Windows Millennium Edition, eller denne versjonen av Windows (konfigurasjon av flere operativsystemer). For å lage en slik konfigurasjon må du installere den forrige versjonen av operativsystemet på en partisjon formatert som FAT32 eller FAT, noe som gjør den til primærpartisjonen (primærpartisjonen kan inneholde operativsystemet). Andre seksjoner tilgjengelig fra tidligere versjoner Windows må også formateres som FAT32. Tidligere versjoner av Windows har bare tilgang til nettverksbaserte NTFS-partisjoner eller -volumer. NTFS-partisjoner på den lokale datamaskinen vil være utilgjengelige.

FAT – fordeler:

Det krever litt RAM for å fungere effektivt.
Rask arbeid med små og mellomstore kataloger.
Disken gjør i gjennomsnitt færre hodebevegelser (sammenlignet med NTFS).
Effektivt arbeid på trege disker.

FETT – ulemper:

Katastrofalt tap av ytelse med økende fragmentering, spesielt for store disker (kun FAT32).
Vansker med tilfeldig tilgang til store (f.eks. 10 % eller mer av diskstørrelsen) filer.
Veldig sakte arbeid med kataloger som inneholder et stort antall filer.

NTFS - fordeler:

Filfragmentering har praktisk talt ingen konsekvenser for selve filsystemet – ytelsen til et fragmentert system forringes kun når det gjelder tilgang til selve fildataene.
Kompleksiteten til katalogstrukturen og antallet filer i én katalog utgjør heller ingen spesielle hindringer for ytelsen.
Rask tilgang til et vilkårlig fragment av en fil (for eksempel redigering av store .wav-filer).
Svært rask tilgang til små filer (noen hundre byte) - hele filen er på samme sted som systemdataene (MFT-posten).

NTFS - ulemper:

Betydelige systemminnekrav (64 MB er det absolutte minimum, mer er bedre).
Trege disker og kontrollere uten Bus Mastering reduserer ytelsen til NTFS kraftig.
Å jobbe med mellomstore kataloger er vanskelig fordi de nesten alltid er fragmenterte.
En disk som fungerer i lang tid med 80 % - 90 % full vil vise ekstremt lav ytelse.

Følgende filsystemer anses som "innfødte" for Linux (det vil si de som det kan installeres på og som det kan starte fra): ext2fs, ext3fs, ext4fs, ReiserFS, XFS, JFS. De tilbys vanligvis som et valg når du installerer de aller fleste distribusjoner. Selvfølgelig er det måter Linux installasjoner til FAT/VFAT/FAT32-filsystemer, men dette er bare for de kjærestene og herrene som forstår perversjoner, og jeg vil ikke snakke om dem.

Hovedkriteriene ved valg av filsystem er vanligvis pålitelighet og ytelse. I noen tilfeller må du også ta hensyn til kompatibilitetsfaktoren - i dette tilfellet betyr det muligheten til andre operativsystemer for å få tilgang til et bestemt filsystem.
Jeg starter anmeldelsen med ReiserFS - fordi grunnen til å skrive dette notatet var spørsmålet: hva bør betraktes som små filer? Tross alt er det velkjent at effektiviteten ved å jobbe med små filer er styrken til dette filsystemet.

Så små filer betyr filer mindre enn en logisk blokk av filsystemet, som i Linux i de fleste tilfeller er lik fire kilobyte, selv om det kan spesifiseres under formatering innenfor visse grenser (avhengig av den spesifikke FS). Det er utallige slike små filer i ethvert Unix-lignende operativsystem. Et typisk eksempel er filene som utgjør treet av FreeBSD-porter, Gentoo-portasjer og lignende portlignende systemer.
I de fleste filsystemer har slike minifiler både sin egen inode (en informasjonsnode som inneholder metainformasjon om filen) og en datablokk, noe som fører til både diskplassforbruk og en reduksjon i ytelsen til filoperasjoner. Spesielt er dette nettopp grunnen til den katastrofale omtenksomheten til FreeBSD-filsystemet (både det gamle, UFS, og det nye, UFS2) når man arbeider med sitt eget portsystem.

I ReiserFS-filsystemet blir det i slike tilfeller ikke tildelt separate blokker for data - det klarer å skyve fildataene direkte inn i inodeområdet. På grunn av dette spares diskplass og ytelsen øker - bokstavelig talt flere ganger sammenlignet med alle andre FS.
Denne håndteringen av små ReiserFS-filer har gitt opphav til legenden om dens upålitelighet. Faktisk, når filsystemet kollapser (det vil si ødeleggelse av tjenesteområder), forsvinner data som ligger sammen med inodene sammen med dem - og ugjenkallelig. Mens i de filsystemene der inoder og datablokker alltid er atskilt romlig, kan sistnevnte teoretisk gjenopprettes. Så for ext2/ext3 er det til og med verktøy som lar deg gjøre dette.

Men som enhver legende gir denne bare inntrykk av autentisitet. For det første gjelder permanent tap av data bare for svært små filer. Blant brukerne er det praktisk talt ingen slike, og alle de andre kan enkelt gjenopprettes fra distribusjonssettet.
For det andre, når jeg snakket om muligheten for å gjenopprette data fra blokker som har mistet forbindelsen til inodene, var det ikke tilfeldig at jeg brukte ordet "teoretisk". For i praksis er denne aktiviteten ekstremt arbeidskrevende og gir ikke et garantert resultat. Alle som har måttet gjøre dette vil være enig i at man bare kan unne seg det av fullstendig fortvilelse. Og dette gjelder alle filsystemer Linux. Så dette aspektet kan neglisjeres når du velger et filsystem.

Når det gjelder generell ytelse, er ReiserFS definitivt raskere enn alle andre journalførte FS, og på noen måter er den overlegen ext2. En hastighetssammenligning av noen vanlige filoperasjoner finner du her.
Men med ReiserFS er kompatibilitetssituasjonen noe verre. Tilgang til det fra Windows-operativsystemer, så vidt jeg vet, er umulig. Noen operativsystemer i BSD-familien (DragonFlyBSD, FreeBSD) støtter dette filsystemet, men i skrivebeskyttet modus. Selv sannsynligheten for at en vilkårlig Linux LiveCD fra tidligere år ikke har ReiserFS-støtte er ikke null.

Og her er det på tide å huske ext3fs. Dens fordel er ikke i det hele tatt i større pålitelighet - dette er den samme legenden som ustabiliteten til ReiserFS. Jeg har ikke hørt mindre om ext3fs-krasj enn om lignende hendelser med ReiserFS. Selv kunne jeg ikke ødelegge verken det ene eller det andre. Bortsett fra at det fungerte med ext2 - men selv da for veldig lenge siden, under tiden for kjerne 2.2 (eller til og med 2.0).

Nei, den største fordelen med ext3fs er dens kompatibilitet - det er garantert å bli lest av ethvert Linux-system. For eksempel, når jeg gjenoppretter fra en gammel LiveCD for hånden - en situasjon som praktisk talt ikke er så utrolig, måtte jeg sette meg inn i det. Igjen, de fleste BSD-systemer kan enkelt forstå ext3fs (riktignok uten logging). For Windows finnes det også, så vidt jeg vet, alle slags drivere og plug-ins for felles filbehandlere(type Totalkommandør), gir tilgang til partisjoner med ext2fs/ext3fs.

Når det gjelder ytelse, etterlater ext3fs et blandet inntrykk. For det første er ytelsen veldig avhengig av loggingsmodusen, hvorav det er tre: med full datalogging, delvis logging og kun logging av metadata. I hver modus viser den forskjellig ytelse på forskjellige typer filoperasjoner. Imidlertid er ytelsen ikke rekord i noe tilfelle.

Men hvis ytelseskravet kommer først, så har ext2fs ingen konkurranse - men i dette tilfellet må du tåle mangelen på logging i det hele tatt. Og følgelig, med lange kontroller av filsystemet i tilfelle feil avslutning - og med volumet av moderne disker kan dette ta veldig lang tid ...

Følgende kan sies om XFS. Når det gjelder kompatibilitet, gjelder alt som ble skrevet for ReiserFS - dessuten, inntil en tid ble det ikke støttet av standard Linux-kjernen. Når det gjelder ytelse, skinner heller ikke XFS, og presterer totalt på omtrent samme nivå som ext3fs. Og operasjonen med å slette filer viser generelt deprimerende treghet.
I følge mine observasjoner lønner det seg å bruke XFS når du ikke bare jobber med store, men med veldig store filer - som faktisk bare er DVD-bilder og videofiler.

La meg gå tilbake til spørsmålet om pålitelighet. En banal strømstans under normalt brukerarbeid tolereres som regel smertefritt av alle journalførte filsystemer (og ingen av dem sikrer sikkerheten til brukeroperasjoner som ikke er skrevet til disk - å redde druknende mennesker forblir arbeidet til de druknende selv). Det er sant at for ethvert filsystem er det mulig å simulere en situasjon der å slå av strømmen vil føre til mer eller mindre alvorlig skade på den. I det virkelige liv er det imidlertid lite sannsynlig at slike situasjoner oppstår. Og du kan helt eliminere dem ved å kjøpe en avbruddsfri strømforsyning - det vil gi mer tillit til sikkerheten til data enn typen filsystem. Vel, i alle fall kan den eneste garantien for å gjenopprette skadede data være regelmessige sikkerhetskopier...

Jeg tror informasjonen presentert ovenfor er nok for et informert valg. Mitt personlige valg de siste årene har vært ReiserFS. Noen ganger, på systemer der det er berettiget å flytte alt mulig utenfor rotpartisjonen, er det fornuftig å bruke ext3fs for rotfilsystemet og ReiserFS for alle andre.

Hvis en separat partisjon er gitt for /boot-katalogen (og dette anbefales når du bruker GRUB bootloader av utviklerne) - for det er intet annet filsystem annet enn ext2fs rettferdiggjort, enhver logging gir ingen mening her. Til slutt, hvis du oppretter en egen partisjon for alle slags multimediematerialer, kan du tenke på XFS.

Hvis vi nærmer oss forklaringen mer metodisk

ext - i de første dagene av Linux var ext2 (utvidet filsystem versjon 2) dominerende. Siden 2002 ble det erstattet av ext3-systemet, som stort sett er kompatibelt med ext2, men også støtter loggingsfunksjoner, og når man jobber med kjerneversjon 2.6 og høyere, ACL-er. Maksimal filstørrelse er 2 TB, maksimal filsystemstørrelse er 8 TB. På slutten av 2008 ble utgivelsen av ext4 offisielt annonsert, som er bakoverkompatibel med ext3, men mange funksjoner implementeres mer effektivt enn før. I tillegg er den maksimale filsystemstørrelsen 1 EB (1 048 576 TB), og du kan forvente at dette er tilstrekkelig en stund. Om reiser - systemet ble oppkalt etter grunnleggeren Hans Reiser, og var det første systemet med loggingsfunksjoner som fikk tilgang til Linux-kjernen for data. SUSE-versjonen av Zp ble til og med ansett som standard en stund. Hovedfordelene med reiser sammenlignet med ext3 er høyere hastighet og plasseringseffektivitet når du arbeider med små filer (og i et filsystem er de fleste filer som regel små). Over tid stoppet imidlertid utviklingen av reiseferdige opp. Det har lenge vært annonsert at versjon 4 vil bli utgitt, som fortsatt ikke er klar, og støtte for versjon 3 har opphørt. Om xfs - xfs-filsystemet ble opprinnelig utviklet for SGI-arbeidsstasjoner som kjører på IRIX-operativsystemet. Xfs er spesielt bra for arbeid med store filer, og er spesielt ideell for arbeid med streaming av video. Systemet støtter kvoter og utvidede attributter (ACL).
jfs

jfs - a66peBHaTypaJFS står for "Journaled File System". Den ble opprinnelig utviklet for IBM og deretter tilpasset for Linux. Jfs nøt aldri mye anerkjennelse på Linux og forsvinner for tiden i en elendig tilværelse, dårligere enn andre filsystemer.
brtfs

brtfs - Hvis det er viljen til de ledende kjerneutviklerne, har brtfs-filsystemet i Linux en lys fremtid. Dette systemet ble utviklet fra bunnen av hos Oracle. Den inkluderer støtte for enhetsmapper og RAID. Brtfs ligner mest på ZFS-systemet utviklet av Sun. Dens mest interessante funksjoner inkluderer on-the-fly filsystemkontroll, samt støtte for SSD-er (solid-state-stasjoner er harddisker drevet av flash-minne). Arbeidet med brtfs vil dessverre ikke bli fullført i overskuelig fremtid. Fedora, fra og med versjon 11, gir muligheten til å installere brtfs, men jeg anbefaler å bruke det kun for filsystemutviklere!
Det finnes ikke noe «raskeste» eller «beste» filsystem – vurderingen avhenger av hva du har tenkt å bruke systemet til. Nybegynnere Linux-brukere som jobber på en lokal datamaskin anbefales å jobbe med ext3, og serveradministratorer med ext4. Selvfølgelig, med ext4 er operasjonshastigheten høyere enn med ext3, men på samme tid, i ext4-systemet er situasjonen med datapålitelighet mye verre - du kan godt miste informasjon hvis systemet plutselig slår seg av.

Hvis du har installert et andre UNIX-lignende operativsystem på datamaskinen din, vil følgende filsystemer være nyttige for deg når du utveksler data (fra ett operativsystem til et annet).

sysv - brukes i SCO, Xenix og Coherent OS.

ufs - brukes i FreeBSD, NetBSD, NextStep og SunOS. Linux kan kun lese informasjon fra slike filsystemer, men kan ikke gjøre endringer i dataene. For å få tilgang til segmenter fra BSD, trenger du i tillegg BSD disklabel-utvidelsen. En lignende utvidelse finnes for SunOS-partisjonstabeller.

ZFS er et relativt nytt system utviklet av Sun for Solaris. Fordi ZFS-koden ikke er GPL-kompatibel, kan den ikke integreres med Linux-kjernen. Av denne grunn støtter Linux kun dette filsystemet indirekte, gjennom FUSE.
Windows, Mac OS X

Følgende filsystemer vil være nyttige når du utveksler informasjon med MS DOS, Windows, OS/2 og Macintosh.

vfat - brukes i Windows 9x/ME. Linux kan lese informasjon fra slike partisjoner og gjøre endringer i den. vfat-systemdrivere lar deg jobbe med eldre MS DOS-filsystemer (8 + 3 tegn).

ntfs - systemet brukes i alle moderne versjoner av Windows: otNT og høyere. Linux kan lese og endre filene sine.

hfs og hfsplus - disse filsystemene brukes i Apple-datamaskiner. Linux kan lese og endre filene sine.

Data-CDer og DVDer bruker vanligvis sine egne filsystemer.

iso9660 - Filsystemet for CD-ROM er beskrevet i ISO-9660 standarden, som kun tillater korte filnavn. Lange navn støttes forskjellig på forskjellige operativsystemer, ved å bruke en rekke utvidelser som er inkompatible med hverandre. Linux kan kjøre både Rockridge-utvidelsen, som er vanlig i UNIX, og Joliet-utvidelsen, utviklet av Microsoft.

udf - dette formatet (universelt diskformat) dukket opp og utviklet som en etterfølger til ISO 9660.

Nettverksfilsystemer

Filsystemer trenger ikke å være på den lokale disken - de
kan kobles til en datamaskin og via et nettverk. Linux-kjernen støtter ulike nettverksfilsystemer, hvorav følgende er de mest brukte.

smbfs/cifs - hjelp til å koble Windows- eller Samba-nettverkskataloger til et katalogtre.

nfs er det viktigste nettverksfilsystemet i UNIX.

coda - dette systemet er veldig likt NFS. Den har mange tilleggsfunksjoner, men den er ikke veldig vanlig.

ncpfs - kjører på NetWare-kjerneprotokollen; oH brukes av Novell Netware.

Virtuelle filsystemer

Linux har flere filsystemer som ikke er laget for å lagre data på harddisken (eller andre lagringsmedier), men kun for å utveksle informasjon mellom kjernen og brukerprogrammer.
devpts - Dette filsystemet gir tilgang til pseudoterminaler (forkortet PTY) via /dev/pts/* i henhold til UNIX-98-spesifikasjonen. (Pseudoterminaler emulerer et serielt grensesnitt. På UNIX/Linux-systemer brukes slike grensesnitt av terminalemulatorer som xterm. Vanligvis brukes enheter som /dev/ttypn. I motsetning til dette definerer UNIX-98-spesifikasjonen nye enheter. Mer detaljert informasjon er rapportert i tekstterminalen H0WT0.)
proc og sysfs - proc-filsystemet brukes til å vise tjenesteinformasjon relatert til kjerne- og prosessadministrasjon. I tillegg til dette bygger sysfs-filsystemet relasjoner mellom kjernen og maskinvaren. Begge filsystemene er montert på /proc og /sys.
tmpfs - Dette systemet er bygget på grunnlag av delt minne i henhold til System V. Det er vanligvis montert i /dev/shm-posisjonen og tillater effektiv utveksling av informasjon mellom to programmer. På noen distribusjoner (som Ubuntu) opprettes også katalogene /var/run og /var/lock ved å bruke filsystemet tmpfs. Filene i disse katalogene brukes av noen nettverksdemoner til å lagre prosessidentifikasjonsnumre samt filtilgangsinformasjon. Takket være tmpfs reflekteres disse dataene nå i RAM. Metoden garanterer høy hastighet, og også at etter at datamaskinen er slått av, vil det ikke være noen filer igjen i katalogene /var/run eller /var/lock.

usbfs - usbfs-filsystemet, som starter med kjerneversjon 2.6 og høyere, gir informasjon om tilkoblede USB-enheter. Det er vanligvis integrert i proc-filsystemet. Om USB-enhetsstøtte i Linux.

Andre filsystemer

auto - faktisk er det ikke noe filsystem under det navnet. Imidlertid kan ordet auto brukes i /etc/fstab eller med mount-kommandoen for å spesifisere filsystemet. I dette tilfellet vil Linux prøve å gjenkjenne filsystemet på egen hånd. Denne metoden fungerer med de fleste store filsystemer.
autofs, autofs4

autofs, autofs4 er heller ikke filsystemer, men kjerneutvidelser som utfører automatisk mount kommando for utvalgte filsystemer. Hvis et filsystem ikke brukes på en stund, kjøres umount-kommandoen automatisk på det. Denne metoden er praktisk først og fremst i tilfeller der bare noen få av mange NFS-kataloger brukes aktivt samtidig.

For å utføre slike operasjoner, kjører /etc/init.d/ autofs-skriptet automatisk automount-programmet når systemet starter. Den konfigureres ved hjelp av filen /etc/auto.master. De tilsvarende programmene installeres automatisk, for eksempel i Red Hat og Fedora. I alle fall aktiveres autofs kun etter å ha konfigurert /etc/auto.master eller /etc/auto.misc.
cramfs og squashfs

cramfs og squashfs - Cram og Squash filsystemer er skrivebeskyttet. De brukes til å "pakke" så mange zippede filer som mulig inn i flash-minne eller ROM (skrivebeskyttet minne).

fuse - FUSE står for Filesystem in Userspace og lar filsystemdrivere utvikles og brukes utenfor kjernen. Derfor brukes FUSE alltid med en ekstern filsystemdriver. FUSE fungerer spesielt med NTFS-driveren ntfs-3g.

gfs og ocfs - Global File System og Cluster File System fra Oracle (Oracle Cluster File System) lar deg bygge gigantiske nettverksfilsystemer som kan nås parallelt av mange datamaskiner samtidig.

jffs and yaffs - Journaling Flash File System og Yet Another Flash File System er spesifikt optimalisert for arbeid med solid-state-stasjoner og flash-medier. Ved hjelp av spesielle algoritmer prøver de å bruke alle minneceller jevnt (slitasjeutjevningsteknologi) for å unngå for tidlig systemsvikt.
Løkke

loop - brukes til å jobbe med pseudoenheter. En loopback-enhet er en adapter som kan få tilgang til en vanlig fil som en blokkeringsenhet. Takket være det kan du plassere hvilket som helst filsystem i hvilken som helst fil, og deretter koble det til katalogtreet ved hjelp av mount. Kjernefunksjonen som er ansvarlig for dette - pseudo-enhetsstøtte - er implementert i loop-modulen.

Det finnes en rekke bruksområder for pseudoenheter. Spesielt kan de brukes når du lager innledende RAM-disker for GRUB eller LILO, når du implementerer krypterte filsystemer, eller tester ISO-bilder for CDer.

Lagringsmediefilsystemer

Filsystemer
ISO 9660
Joliet ISO 9660 filsystemutvidelse.
Rock Ridge (RRIP, IEEE P1282) – en ISO 9660 filsystemutvidelse designet for å lagre filattributter som brukes i POSIX-operativsystemer
Amiga Rock Ridge Extensions
El Torito
Apple ISO9660-utvidelser
HFS, HFS+
Universell Diskformat spesifikasjon av et filsystemformat uavhengig av operativsystemet for lagring av filer på optiske medier. UDF er en implementering av ISO/IEC 13346-standarden
Mount Rainier

Fil Linux-system- dette er oftest ext4. Den er journalført og lar deg enkelt jobbe med data når du løser de aller fleste problemer. Det finnes imidlertid andre. Hovedtyper av filsystemer og prinsipper for å jobbe med dem vil bli diskutert innenfor rammen av dette materialet.

Typer Linux-filsystemer og deres funksjoner

Karakteristiske trekk er hastigheten på arbeidet med filer, sikkerhet og parametere (som blokkstørrelse) som eksisterer som standard og angis når du oppretter FS. Den kanskje viktigste funksjonen er tilstedeværelsen av et magasin. Systemloggen registrerer data eller metadata(kun overskrifter) som informasjon kan gjenopprettes fra i tilfelle feil.

Et filsystem kan opprettes på hvilken som helst enhet: på en disk eller systempartisjon.

EXT2 filsystem

EXT2 er for tiden et utdatert filsystem som praktisk talt ikke brukes i moderne installasjoner. Den største ulempen er mangelen på logging, som følgelig gjør det umulig å gjenopprette data i tilfelle feil. Brukes fortsatt på bærbare lagringsmedier som USB. Et magasin er ikke nødvendig for dem, siden det tar en viss plass.

Den garanterer også maksimal driftshastighet.

  • for EXT2 maksimal filstørrelse -2 TB

EXT3 filsystem

Erstattet EXT2, hovedfunksjonen er utseendet til magasinet, er fullt bakoverkompatibel med EXT2 (EXT2 kan fritt konverteres til EXT3). I dag er det også sjeldent; EXT4 brukes nesten alltid.

Journal - et spesielt område i minnet der informasjon om alle endringer er registrert

  • for EXT3 maksimal filstørrelse -2 TB
  • maksimal størrelse på alle filer er 32 TB
  • hver katalog kan ha opptil 32 000 underkataloger

Ved journalføring er det tre alternativer (spesifisert når du oppretter filsystemet):

  • journal – metadata, samt selve informasjonen, inn i journalen
  • bestilt – standardalternativ, kun metadata lagres selv etter skriving til disk
  • tilbakeskrivning – kun metadata lagres også, du kan velge å lagre dem før eller etter skriving til disk

EXT4 filsystem

Den moderne versjonen av det utvidede filsystemet, dette er den som oftest brukes

  • maksimal filstørrelse -2 TB 16 TB
  • Maksimal størrelse på alle filer er 1 EB (exabyte). 1 EB = 1024 PB (petabyte). 1 PB = 1024 TB (terabyte).
  • hver katalog kan ha opptil 64 000 underkataloger

I EXT4 kan logging slås av ved å stille inn alternativet data når den er montert i av

EXT som det viktigste Linux-filsystemet og operativ praksis

Filsystemet opprettes med kommandoen mk2fs

Det nødvendige loggingsalternativet er spesifisert under montering, for eksempel:

monter /dev/vdc /mnt/1 -t ext3 -o data=journal

Konvertering fra EXT2 E til XT3

ReiserFS

ReiserFS (og den moderne implementeringen av Reiser4 med SELinux-støtte) har god ytelse og er svært produktiv - spesielt når du arbeider med store antall små filer. ReiserFS tildeler ikke inoder for hver liten fil, men behandler dem sammen, og ReiserFS bruker også en journal med flere tilgjengelige alternativer. Foreløpig støttes filsystemet av utviklere fra Russland.

Du kan opprette en FS for en enhet med kommandoen

XFS

XFS er et journalfilsystem. Bruker RAMå lagre informasjon, slik at tap av data er mulig – for eksempel når strømmen går.

For å bruke XFS på Ubuntu må du installere pakker xfsprogs Og xfsdump

vfat

Linux-filsystemet finnes også i Windows-miljøet. Den brukes når du trenger å organisere delt tilgang til visse disker og partisjoner av klienter med forskjellige operativsystemer. I andre tilfeller anbefales det ikke å bruke det, da det kan oppstå vanskeligheter når du arbeider i Linux.

(Andre utvidede filsystem).

· Historie om utviklingen av Linux-filsystemer

· Diskpartisjonsstruktur i ext2fs

·

· Kataloger

· Enhetsfiler

·

·

· EXT2fs-bibliotek

· EXT2fs systemverktøy

· Ytelsesberegning

Matematisk fakultet

Programvare program

2. år 5. gr.

Chichirov Andrey

Falsk system EXT2fs (Second Extended File System).

Historie om utviklingen av Linux-filsystemer

De første versjonene av Linux ble utviklet basert på operativsystemet Minix. Det ville være lettere å dele diskene mellom de to systemene enn å utvikle et nytt filsystem, så Linus Torvalds bestemte seg for å introdusere Linux-støtte for Minix-filsystemet. På den tiden var dette filsystemet et ganske effektivt programvareprodukt med et relativt lite antall feil.

Imidlertid var begrensningene knyttet til strukturen til Minix-filsystemet ganske høye, så de begynte å tenke på å utvikle et nytt filsystem for Linux.

For å forenkle implementeringen av det nye filsystemet i Linux-kjernen, ble et virtuelt filsystem (VFS) utviklet. VFS ble opprinnelig skrevet av Chris Provenzano og deretter omskrevet av Linus Torvalds før den ble integrert i kjernen.

Etter å ha installert VFS i kjernen, ble et nytt filsystem, EXTfs (Extended File System), utviklet i april 1992 og lagt til Linux versjon 0.96c. I det nye filsystemet ble to betydelige begrensninger for Minix-systemet fjernet: maksimal størrelse kunne nå 2 gigabyte, og maksimal filnavnlengde kunne være 255 tegn. Dette var en forbedring i forhold til Minix-filsystemet, selv om det fortsatt var noen problemer. Det var ingen støtte for delt tilgang, modifikasjon av indeksbeskrivelsen og modifikasjon av filendringstidsceller. Dette filsystemet brukte koblede lister for å operere på gratis blokker og inoder, noe som i stor grad påvirket systemytelsen: over tid ble listene uordnet og usortert, noe som førte til fragmentering av filsystemet.

Løsningen på disse problemene var utgivelsen i januar 1993 av alfaversjoner av to nye filsystemer: Xia og EXT2fs (Second Extended File System). For det meste var Xia-filsystemet basert på Minix, med noen få nye funksjoner lagt til. Dette var hovedsakelig muligheten til å jobbe med lange filnavn, støtte for større diskpartisjoner og støtte for tre filskifttidsceller. På den annen side var EXT2fs basert på EXTfs med mange forbedringer og tillegg. Det hadde også muligheter for fremtidig utvikling.

Da disse to filsystemene ble utgitt, var de funksjonelt omtrent like. Xia-systemet var mer pålitelig enn EXT2fs ved å minimere det. Etter hvert som de ble mer utbredt, ble feil i EXT2fs-systemet oppdaget og et stort antall nye funksjoner og forbedringer ble lagt til. EXT2fs-filsystemet er nå veldig pålitelig og har blitt de facto Linux-filsystemstandarden.

Tabellen nedenfor gir generell informasjon om funksjonaliteten som tilbys av ulike filsystemer.

Minix FS

Ext FS

Ext2FS

Xia FS

Maksimal filsystemstørrelse

Maksimal fillengde

Maksimal filnavnlengde

Støtte for tre filskifttidsceller

Utvidbarhet

Tilpassbar blokkstørrelse

Informasjonsbeskyttelse

Om nødvendig, lengden på filnavnet i Ext 2 kan økes til 1012.

EXT2fs reserverer et visst antall blokker for root-brukeren. Vanligvis er dette 5 % av totalen, noe som gjør at systemadministratoren kan unngå å gå tom for harddiskplass når den er fylt med andre brukeres prosesser.

Diskpartisjonsstruktur i ext2fs

Harddiskprodusenter sender vanligvis produktene sine på lavt nivå formatert. Så vidt jeg vet, betyr dette at hele diskplassen er delt inn i "sektorer" på 512 byte i størrelse ved hjelp av spesielle etiketter. En slik disk (eller diskpartisjon) må være klargjort for bruk på et spesifikt operativsystem. I MS-DOS eller Windows kalles forberedelsesprosedyren formatering, og i Linux - å lage et filsystem. Opprette et filsystem ext2fs består av å lage en viss logisk struktur i en diskpartisjon. Denne strukturen er konstruert som følger. Først tildeles et oppstartsområde på disken. Oppstartsområdet opprettes på et hvilket som helst filsystem. På den primære partisjonen inneholder den en oppstartsrecord - et stykke kode som starter prosessen med å laste operativsystemet ved oppstart. Dette området brukes ikke på andre partisjoner. Resten av diskplassen er delt inn i blokker. En blokk kan være 1, 2 eller 4 kilobyte stor. En blokk er en adresserbar enhet av diskplass. Filer er tildelt i blokker, så det er avveininger ved valg av blokkstørrelse. Stor størrelse blokk reduserer som regel antall disktilganger når du leser eller skriver en fil, men det øker andelen bortkastet plass, spesielt når det er et stort antall små filer.

Blokker i deres område er kombinert i grupper av blokker. Grupper av blokker i et filsystem og blokker innenfor en gruppe er nummerert sekvensielt, og starter med 1. Den første blokken på en disk er nummerert 1 og tilhører gruppe nummer 1. Totalt antall blokker på en disk (i en diskpartisjon) er en divisor av diskens kapasitet, uttrykt i sektorer. Og antall blokkgrupper trenger ikke å dele antall blokker, fordi den siste blokkgruppen kanskje ikke er komplett. Begynnelsen av hver gruppe av blokker har en adresse, som kan fås som ((gruppenummer - 1)* (antall blokker i gruppen)).

Hver gruppe av blokker har samme struktur. Strukturen er presentert i tabellen nedenfor.

Strukturen til en diskpartisjonsgruppe med blokker i ext2fs

Det første elementet i denne strukturen (superblokk) er det samme for alle grupper, og resten er individuelle for hver gruppe. Superblokken lagres i den første blokken i hver blokkgruppe (bortsett fra gruppe 1, som har en oppstartsrecord i den første blokken). Superblokk er utgangspunktet for filsystemet. Den er 1024 byte stor og Alltid plassert ved offset 1024 byte fra begynnelsen av filsystemet. Tilstedeværelsen av flere kopier av en superblokk forklares av den ekstreme betydningen av dette elementet i filsystemet. Superblokk-duplikater brukes når du gjenoppretter et filsystem etter feil.

Informasjonen som er lagret i superblokken brukes til å organisere tilgang til resten av dataene på disken. Superblokken bestemmer størrelsen på filsystemet, maksimalt antall filer i partisjonen, mengden ledig plass, og inneholder informasjon om hvor du skal lete etter ikke-allokerte områder. Når operativsystemet starter, leses superblokken inn i minnet og alle endringer i filsystemet gjenspeiles først i en kopi av superblokken som ligger i operativsystemet og skrives til disk bare periodisk. Dette forbedrer systemytelsen fordi mange brukere og prosesser stadig oppdaterer filer. På den annen side, når systemet er slått av, må superblokken skrives til disk, som ikke tillater å slå av datamaskinen enkel nedleggelse ernæring. Ellers, neste gang du starter opp, vil ikke informasjonen som er registrert i superblokken samsvare med den virkelige tilstanden til filsystemet.

Superblokken har følgende struktur

Feltnavn

Type

En kommentar

s_inodes_count

ULONG

Antall inoder i filsystemet

s_blocks_count

ULONG

Antall blokker i filsystemet

s_r_blocks_count

ULONG

Antall blokker reservert for superbruker

s_free_blocks_count

ULONG

Gratis blokkteller

s_free_inodes_count

ULONG

Gratis inodeteller

s_first_data_block

ULONG

Den første blokken som inneholder data. Avhengig av blokkstørrelsen kan dette feltet være 0 eller 1.

s_log_block_size

ULONG

Logisk blokkstørrelsesindikator: 0 = 1 KB; 1 = 2 KB; 2 = 4 KB.

s_log_frag_size

LANG

Fragmentstørrelsesindikator (det ser ut til at fragmentkonseptet ikke brukes for øyeblikket)

s_blokker_per_gruppe

ULONG

Antall blokker i hver blokkgruppe

s_frags_per_group

ULONG

Antall fragmenter i hver blokkgruppe

s_inoder_per_gruppe

ULONG

Antall inoder i hver blokkgruppe

s_mtime

ULONG

Tiden filsystemet sist ble montert.

s_wtime

ULONG

Tidspunktet da filsystemet sist ble skrevet til

s_mnt_count

USKORT

Teller for antall filsystemmonteringer. Hvis denne telleren når verdien spesifisert i neste felt (s_max_mnt_count), må filsystemet kontrolleres (dette gjøres ved omstart) og telleren tilbakestilles til null.

s_max_mnt_count

KORT

Et tall som bestemmer hvor mange ganger filsystemet kan monteres

s_magi

USKORT

"Magisk tall" (0xEF53) som indikerer at filsystemet er av typen ex2fs

s_stat

USKORT

Flagg som indikerer gjeldende tilstand til filsystemet (er det rent osv.)

s_errors

USKORT

Flagg som spesifiserer prosedyrer for behandling av feilmeldinger (hva du skal gjøre hvis feil blir funnet).

s_pad

USKORT

Fylling

s_lastcheck

ULONG

Tidspunkt for siste filsystemkontroll

s_sjekkintervall

ULONG

Maksimal tidsperiode mellom filsystemkontroller

s_creator_os

ULONG

En indikasjon på hvilken type OS filsystemet ble opprettet i

s_rev_level

ULONG

Versjon (revisjonsnivå) av filsystemet.

s_reservert

ULONG

Utfylling på opptil 1024 byte

Etter superblokken er en beskrivelse av gruppen av blokker (gruppebeskrivelser). Denne beskrivelsen er en matrise med følgende struktur.

Feltnavn

Type

Hensikt

bg_block_bitmap

ULONG

Adressen til blokken som inneholder blokkbitmappen til denne gruppen

bg_inode_bitmap

ULONG

Adressen til blokken som inneholder inode punktgrafikk til denne gruppen

bg_inode_table

ULONG

Adressen til blokken som inneholder inodetabellen til denne gruppen

bg_free_blocks_count

USKORT

Teller for antall ledige blokker i denne gruppen

bg_free_inodes_count

USKORT

Antall ledige inoder i denne gruppen

bg_used_dirs_count

USKORT

Antall inoder i en gitt gruppe som er kataloger

bg_pad

USKORT

Fylling

bg_reserved

ULONG

Fylling

Størrelsen på blokkgruppebeskrivelsen kan beregnes som (block_group_size_in_ext2 * number_of_groups) / block_size(rund om nødvendig).

Informasjonen som er lagret i gruppebeskrivelsen brukes til å finne blokk- og inode-bitmaps, samt inodetabellen. Ikke glem at blokker og grupper av blokker er nummerert fra 1.

En blokkbitmap er en struktur der hver bit indikerer om den tilsvarende blokken er allokert til en fil. Hvis biten er 1, er blokken opptatt. Dette kartet brukes til å søke etter ledige blokker i tilfeller der det er nødvendig å allokere plass til en fil.Blokkbitmappen opptar et antall blokker tilsvarende (antall_blokker_i_gruppe / 8) / blokkstørrelse(rund om nødvendig).

Inode bitmap utfører en lignende funksjon som inodetabellen: den viser hvilke inoder som er i bruk.

Det neste området i blokkgruppestrukturen brukes til å lagre filen inodetabell. Strukturen til selve inoden diskuteres mer detaljert i neste underavsnitt.

Vel, og til slutt, all gjenværende plass i gruppen av blokker er tildelt for lagring av de faktiske filene.

Filsystem Ext 2 er preget av:

  • hierarkisk struktur,
  • koordinert behandling av datasett,
  • dynamisk filtype,
  • beskyttelse av informasjon i filer,
  • behandle perifere enheter (som terminaler og båndenheter) som filer.

Intern filrepresentasjon

Hver fil i Ext 2-systemet har en unik indeks. Indeksen inneholder informasjonen som trengs av enhver prosess for å få tilgang til filen. Behandler tilgangsfiler ved å bruke et veldefinert sett med systemanrop og identifiserer filen med en streng med tegn som fungerer som et kvalifisert filnavn. Hvert sammensatt navn identifiserer en fil unikt, så systemkjernen konverterer dette navnet til en filindeks Indeksen inkluderer en adressetabell der filinformasjonen er plassert på disken. Siden hver blokk på en disk adresseres av sitt eget nummer, lagrer denne tabellen en samling diskblokknumre. For å øke fleksibiliteten legger kjernen til en fil én blokk om gangen, slik at filens informasjon kan spres over hele filsystemet. Men dette oppsettet kompliserer oppgaven med å søke etter data. Adressetabellen inneholder en liste over blokknumre som inneholder informasjon som tilhører en fil, men enkle beregninger viser at en lineær liste over filblokker i en indeks er vanskelig å administrere. For at en liten indeksstruktur skal tillate arbeid med store filer, bringes tabellen over diskblokkadresser i tråd med strukturen vist i figur 1

De fleste filene i et Ext 2-system er ikke større enn 10 KB eller til og med 1 KB! Fordi 10 KB av en fil er plassert i direkte adresseringsblokker, kan de fleste dataene som er lagret i filer nås på en enkelt disktilgang. Derfor, i motsetning til tilgang til store filer, er det raskt å jobbe med filer i standardstørrelse.

Filinoder

Hver fil på disken er assosiert med én og bare én filinode, som identifiseres med sekvensnummeret - filindeksen. Dette betyr at antall filer som kan opprettes på et filsystem er begrenset av antall inoder, som enten spesifiseres eksplisitt når filsystemet opprettes eller beregnes basert på den fysiske størrelsen på diskpartisjonen. Inoder finnes på disken i statisk form, og kjernen leser dem inn i minnet før de arbeider med dem.

Filinoden har følgende struktur:

Feltnavn

Type

Beskrivelse

I_modus

USKORT

Type og tilgangsrettigheter til denne filen.

I_uid

USKORT

Fileieridentifikator (Eier-Uid).

I_størrelse

ULONG

Filstørrelse i byte.

Jeg_en gang

ULONG

Tidspunkt for siste tilgang til filen (tilgangstid).

I_ctime

ULONG

Tid for filoppretting.

I_mtime

ULONG

Tidspunktet for siste endring av filen.

I_dtime

ULONG

Filslettingstid.

Jeg_gid

USKORT

Gruppe-ID (GID).

I_links_count

USKORT

Linker teller.

I_blokker

ULONG

Antall blokker som er okkupert av filen.

Jeg_flagger

ULONG

Filflagg (Fil flagg)

I_reserved1

ULONG

Reservert for OS

Jeg_blokkerer

ULONG

Pekere til blokker der fildata er skrevet (et eksempel på direkte og indirekte adressering i fig. 1)

I_versjon

ULONG

Filversjon (for NFS)

I_file_acl

ULONG

ACL-fil

I_dir_acl

ULONG

Katalog ACL

I_faddr

ULONG

Fragmentadresse

I_frag

UCHAR

Fragmentnummer

I_fsize

UCHAR

Fragmentstørrelse

I_pad1

USKORT

Fylling

I_reserved2

ULONG

Forbeholdt

Feltet for filtype og tilgangsrettigheter er et to-byte-ord, som hver bit fungerer som et flagg som indikerer filens forhold til en bestemt type eller innstillingen for en spesifikk filrettighet.

Identifikator

Betydning

Formålet med flagget (felt)

S_IFMT

F000

Filtype maske

S_IFSOCK

A000

Domenekontakt

S_IFLNK

C000

S_IFREG

8000

Vanlig fil

S_IFBLK

6000

Blokkorientert enhet

S_IFDIR

4000

Katalog

S_IFCHR

2000

Byte-orientert (tegn) enhet

S_IFIFO

1000

Navngitt rør (fifo)

S_ISUID

0800

SUID - bytt eierbit

S_ISGID

0400

SGID - gruppebyttebit

S_ISVTX

0200

Oppgavesparingsbit (klistrebit)

S_IRWXU

01C0

Maske for fileierrettigheter

S_IRUSR

0100

Rett til å lese

S_IWUSR

0080

Skriv riktig

S_IXUSR

0040

Rett til å henrette

S_IRWXG

0038

Maske for grupperettigheter

S_IRGRP

0020

Rett til å lese

S_IWGRP

0010

Skriv riktig

S_IXGRP

0008

Rett til å henrette

S_IRWXO

0007

Maske av rettigheter til andre brukere

S_IROTH

0004

Rett til å lese

S_IWOTH

0002

Skriv riktig

S_IXOTH

0001

Rett til å henrette

Blant inodene er det flere inoder som er reservert for spesielle formål og spiller en spesiell rolle i filsystemet. Dette er følgende beskrivelser

Identifikator

Betydning

Beskrivelse

EXT2_BAD_INO

En inode som viser adressene til dårlige blokker på disken (Bad blocks inode)

EXT2_ROOT_INO

Inode til filsystemets rotkatalog (Root inode)

EXT2_ACL_IDX_INO

ACL inode

EXT2_ACL_DATA_INO

ACL inode

EXT2_BOOT_LOADER_INO

Boot loader inode

EXT2_UNDEL_DIR_INO

Angre sletting av katalog inode

EXT2_FIRST_INO

Første uforbeholdne inode

Det viktigste håndtaket på denne listen er rotkataloghåndtaket. Dette håndtaket peker til rotkatalogen, som, som alle kataloger, består av oppføringer med følgende struktur:

Feltnavn

Type

Beskrivelse

Inode

ULONG

filinodenummer

rec_len

USKORT

Lengden på denne oppføringen

navn_len

USKORT

Lengde på filnavn

Navn

CHAR

Filnavn

En individuell katalogoppføring kan ikke krysse en blokkgrense (det vil si at den må ligge helt innenfor en enkelt blokk). Derfor, hvis neste post ikke passer helt inn i en gitt blokk, overføres den til neste blokk, og den forrige posten fortsetter slik at den fyller blokken til slutten.

Figur 1 Direkte og indirekte adresseringsblokker i indeksen

Figur 2 Filstørrelse i byte med en blokkstørrelse på 1 KB

Figur 3. Eksempel på en diskindeks

Figur 3 viser diskindeksen til en bestemt fil. Denne indeksen tilhører en vanlig fil hvis eier er "mjb" og hvis størrelse er 6030 byte. Systemet lar brukeren "mjb" lese, skrive og kjøre filen; medlemmer av "os"-gruppen og alle andre brukere har kun lov til å lese eller kjøre filen, men ikke skrive data til den. Filen ble sist lest 23. oktober 1984 kl. 13.45 og sist skrevet til 22. oktober 1984 kl. 10.30. Indeksen ble sist endret 23. oktober 1984 kl. 13.30, selv om ingen informasjon ble skrevet til filen på det tidspunktet. Kjernen koder alle ovennevnte data i en indeks. Legg merke til forskjellen i å skrive innholdet i indeksen og innholdet i filen til disk. Innholdet i en fil endres bare når det skrives til filen. Innholdet i indeksen endres både når innholdet i filen endres og når fileier, tilgangsrettigheter og pekersett endres. Endring av innholdet i en fil fører automatisk til at indeksen justeres, men justering av indeksen betyr ikke at innholdet i filen endres.

Kataloger

Kataloger er filene som den hierarkiske strukturen til filsystemet er bygget opp fra; de spiller en viktig rolle i å gjøre filnavnet om til et indeksnummer. En katalog er en fil hvis innhold er et sett med oppføringer som består av indeksnummeret og filnavnet inkludert i katalogen. Et kvalifisert navn er en streng med tegn som avsluttes av null-tegnet og atskilt med en skråstrek ("/") i flere komponenter. Hver komponent unntatt den siste må være navnet på en katalog, men den siste komponenten kan være navnet på en fil som ikke er en katalog. I UNIX versjon V er lengden på hver komponent begrenset til 14 tegn; Således, sammen med de 2 bytene som er tildelt for indeksnummeret, er størrelsen på katalogoppføringen 16 byte.

Byte offset
inne i katalogen

Indeksnummer
(2 byte)

Navnfil

1798

i det

1276

fsck

clri

1268

motd

1799

montere

mknod

2114

passwd

1717

umount

1851

sjekkliste

fsdbld

konfig

1432

getty

brak

mkfs

Figur 4 /etc katalogformat

Figur 4 viser formatet til "etc"-katalogen. Hver katalog inneholder filer hvis navn er angitt med en prikk og to punkter ("." og "..") og hvis indeksnummer sammenfaller med indeksnumrene til henholdsvis den gitte katalogen og den overordnede katalogen. Indeksnummer for filen "." i katalogen "/etc" har en adresse ved offset 0 og en verdi på 83. Inodenummeret for filen ".." har en adresse ved offset 16 fra starten av katalogen og en verdi på 2. Oppføringer i katalogen kan være tom, men inodenummeret er 0. For eksempel er oppføringen på adresse 224 i "/etc"-katalogen tom, til tross for at den en gang inneholdt et inngangspunkt for en fil kalt "crash". Mkfs-programmet initialiserer filsystemet slik at inodenumrene for filer er "." og ".." i rotkatalogen er det samme som rotindeksnummeret til filsystemet.

Kjernen lagrer data i en katalog akkurat som den gjør i en vanlig filtype, ved hjelp av en indeksstruktur og blokker med direkte og indirekte adresseringsnivåer. Prosesser kan lese data fra kataloger på samme måte som de leser vanlige filer, men eksklusiv skrivetilgang til katalogen er reservert av kjernen, noe som sikrer at katalogstrukturen er korrekt. Katalogtillatelser har følgende betydning: lesetillatelse gir prosesser muligheten til å lese data fra katalogen; skrivetillatelse tillater en prosess å lage nye oppføringer i en katalog eller fjerne gamle (ved å bruke systemoperasjonene opprette, mknod, lenke og fjerne koblinger), og dermed endre innholdet i katalogen; Utførelsesretten lar en prosess søke i en katalog etter filnavn (siden det er meningsløst å "utføre" en katalog).

Når en prosess bruker en filbane, ser kjernen i katalogene etter det tilsvarende inodenummeret. Etter at filnavnet er konvertert til et inodenummer, plasseres inoden i minnet og brukes deretter i påfølgende forespørsler.

Konseptet med Unix-filsystemer inkluderer konseptet med en lenke. En enkelt inode kan assosieres med flere filnavn. Deskriptoren inneholder et felt som lagrer nummeret som filen er knyttet til. Å legge til en lenke består av å lage en katalogoppføring der inodenummeret peker til en annen inode, og øke koblingstelleren i inoden. Når en lenke fjernes, reduserer kjernen lenketelleren og fjerner håndtaket hvis telleren blir null.

Slike lenker kalles harde lenker og kan bare brukes innenfor ett filsystem (du kan ikke opprette en lenke for en fil fra et annet filsystem). Dessuten kan en hard link bare peke til en fil (en hard link til en katalog kan forårsake en løkke i filsystemet).

På de fleste Unix-systemer er det en annen type kobling. Disse koblingene, som bare inneholder filnavnet, kalles symbolske. Når kjernen behandler slike lenker, når filbanen konverteres til en inode, erstatter kjernen lenkenavnet med innholdet i inoden (det vil si målfilnavnet) og tolker filbanen på nytt. Siden en symbolsk lenke ikke peker til en inode, er det mulig å lage lenker til filer som ligger på et annet filsystem. Disse koblingene kan peke til alle typer filer, selv ikke-eksisterende. Symbolske lenker er mye brukt fordi de ikke har de samme begrensningene som harde lenker har. De tar imidlertid opp litt plass på disken der inoden og datablokkene er plassert. Bruken av dem kan føre til noen forsinkelser i å konvertere filbanen til en inode, på grunn av det faktum at kjernen må tolke filbanen på nytt når en symlink behandles.

Enhetsfiler

I Unix-lignende operativsystemer får du tilgang til enheter via spesielle filer. En slik fil tar ikke opp plass i filsystemet. Det er bare et tilgangspunkt til enhetsdriveren.

Det finnes to typer enhetsfiler: tegn og blokk. Når du bruker en tegntype, er det mulig å utveksle data med enheten kun i tegnmodus, mens enhetsfiler av blokktype tillater bare utveksling av blokker ved hjelp av en buffer. Når en I/O-forespørsel sendes til en enhetsfil, videresendes forespørselen til den aktuelle enhetsdriveren. Hver slik fil har et hovednummer som identifiserer typen enhet, og et mindre nummer som identifiserer selve enheten.

Ytterligere funksjoner i EXT2fs

I tillegg til standard Unix-funksjoner, gir EXT2fs noen tilleggsfunksjoner som vanligvis ikke støttes av Unix-filsystemer.

Filattributter lar deg endre hvordan kjernen reagerer når du arbeider med sett med filer. Du kan angi attributter på en fil eller katalog. I det andre tilfellet arver filer opprettet i denne katalogen disse attributtene.

Under systemmontering kan noen funksjoner relatert til filattributter angis. Monteringsalternativet lar administratoren velge hvordan filer opprettes. I et BSD-spesifikt filsystem opprettes filer med samme gruppe-ID som den overordnede katalogen. Funksjonene til System V er noe mer komplekse. Hvis en katalog har sin setgid-bit satt, da opprettet filer arv gruppe-ID-en til den katalogen, og underkataloger arver gruppe-ID-en og setgid-biten. Ellers opprettes filer og kataloger med den primære gruppe-IDen for anropsprosessen.

EXT2fs-systemet kan bruke synkron datamodifikasjon tilsvarende BSD system. Monteringsalternativet lar administratoren spesifisere at alle data (inoder, bitblokker, indirekte blokker og katalogblokker) skrives til disk synkront når de endres. Dette kan brukes til å oppnå høy dataopptakskapasitet, men resulterer også i dårlig ytelse. I virkeligheten brukes vanligvis ikke denne funksjonen fordi den, i tillegg til å forringe ytelsen, kan føre til tap av brukerdata som ikke blir flagget ved kontroll av filsystemet.

EXT2fs lar deg velge den logiske blokkstørrelsen når du oppretter et filsystem. Den kan være 1024, 2048 eller 4096 byte stor. Bruk av større blokker resulterer i raskere I/O-operasjoner (siden færre diskforespørsler gjøres), og derfor mindre hodebevegelse. På den annen side fører bruk av store blokker til bortkastet diskplass. Vanligvis blir ikke den siste blokken i en fil fullstendig brukt til å lagre informasjon, så når blokkstørrelsen øker, øker mengden bortkastet diskplass.

EXT2fs lar deg bruke akselererte symbolske lenker. Når du bruker slike lenker, brukes ikke filsystemdatablokker. Destinasjonsfilnavnet lagres ikke i datablokken, men i selve inoden. Denne strukturen lar deg spare diskplass og øke hastigheten på behandlingen av symbolske lenker. Selvfølgelig er plassen reservert for et håndtak begrenset, så ikke alle lenker kan representeres som en akselerert lenke. Maksimal lengde på et filnavn i en akselerert kobling er 60 tegn. I nær fremtid er det planlagt å utvide denne ordningen for små filer.

EXT2fs overvåker tilstanden til filsystemet. Kjernen bruker et eget felt i superblokken for å indikere tilstanden til filsystemet. Hvis filsystemet er montert i lese-/skrivemodus, er tilstanden satt til "Ikke rent". Hvis den er demontert eller montert på nytt i skrivebeskyttet modus, er dens tilstand satt til "Ren". Under systemoppstart og kontroll av filsystemstatus brukes denne informasjonen til å avgjøre om en filsystemsjekk er nødvendig. Kjernen plasserer også noen feil i dette feltet. Når kjernen oppdager et misforhold, merkes filsystemet som "Feil". Filsystemkontrollen tester denne informasjonen for å sjekke systemet, selv om statusen faktisk er Ren.

Å ignorere filsystemtesting i lang tid kan noen ganger føre til noen problemer, så EXT2fs inkluderer to metoder for regelmessig kontroll av systemet. Superblokken inneholder systemmontert teller. Denne telleren økes hver gang systemet monteres i lese-/skrivemodus. Hvis verdien når maksimum (den er også lagret i superblokken), begynner filsystemets testprogram å sjekke den, selv om tilstanden er "Ren". Den siste kontrolltiden og det maksimale intervallet mellom kontrollene lagres også i superblokken. Når det maksimale intervallet mellom skanninger er nådd, ignoreres tilstanden til filsystemet og skanningen startes.

EXT2fs-systemet inneholder verktøy for å konfigurere det. Tune2fs-programmet kan brukes til å endre:

  • handlinger når en feil oppdages. Når kjernen oppdager et avvik, er filsystemet merket som "Feil" og en av følgende tre handlinger kan utføres: fortsette kjøringen, remonter filsystemet i skrivebeskyttet modus for å unngå skade, eller start systemet på nytt for å sjekke filsystem.
  • maksimal monteringsverdi.
  • maksimalt intervall mellom kontrollene.
  • antall logiske blokker reservert for root-brukeren.

Alternativer spesifisert ved mount kan også brukes til å endre hva kjernen gjør når den oppdager en feil.

Ved å bruke attributter kan brukere slette sensitive filer. Når en slik fil slettes, skrives tilfeldig informasjon til blokkene som tidligere ble brukt til å plassere denne filen. Dette forhindrer utenforstående fra å få tilgang til det tidligere innholdet i denne filen ved hjelp av et diskredigeringsprogram.

Nye filtyper har nylig blitt lagt til EXT2fs-systemet, hentet fra 4.4 BSD-filsystemet. Filer av den første typen kan kun brukes til lesing: ingen har rett til å endre eller slette dem. Dette kan brukes til å beskytte viktige konfigurasjonsfiler. En annen type fil er en fil som kan åpnes i skrivemodus, og data kan bare legges til på slutten av filen. Filer av denne typen kan heller ikke slettes eller gis nytt navn. De kan brukes som loggfiler, som bare kan vokse i størrelse.

Ytelsesoptimalisering

EXT2fs-systemet inneholder mange funksjoner som optimerer ytelsen, noe som fører til økt hastighet på informasjonsutveksling ved lesing og skriving av filer.

EXT2fs bruker aktivt diskbufferen. Når en blokk må leses, sender kjernen en I/O-operasjonsforespørsel til flere tilstøtende blokker. Dermed prøver kjernen å sørge for at den neste blokken som skal leses allerede er lastet inn i diskbufferen. Slike operasjoner utføres vanligvis når du leser filer sekvensielt.

EXT2fs-systemet inneholder også et stort antall optimaliseringer for informasjonsplassering. Blokkgrupper brukes til å gruppere tilsvarende inoder og datablokker. Kjernen prøver alltid å plassere datablokkene til én fil i samme gruppe, så vel som dens beskrivelse. Dette er ment å redusere bevegelsen til drivhodene når du leser beskrivelsen og dens tilsvarende datablokker.

Når du skriver data til en fil, forhåndstildeler EXT2fs opptil 8 sammenhengende blokker når en ny blokk tildeles. Denne metoden lar deg oppnå høy ytelse under stor systembelastning. Dette gjør det også mulig å plassere filer i sammenhengende blokker, noe som gjør den påfølgende lesingen raskere.

EXT2fs bibliotek

For å forenkle bruken av EXT2fs-ressurser og driften av kontrollstrukturene til dette filsystemet, ble libext2fs-biblioteket utviklet. Dette biblioteket inneholder funksjoner som kan brukes til å definere og endre EXT2-filsystemdata ved direkte tilgang til den fysiske enheten.

De fleste EXT2fs-verktøy (mke2fs, e2fsck, tune2fs, dumpe2fs, debugfs, etc.) bruker dette biblioteket. Dette forenkler modifikasjoner av disse verktøyene betydelig, siden eventuelle endringer for å introdusere tilleggsfunksjoner i EXT2fs-filsystemet bare må gjøres i EXT2fs-biblioteket.

Siden grensesnittet til EXT2fs-biblioteket er ganske bredt og abstrakt, kan programmer som krever direkte tilgang til filsystemet enkelt skrives med dens hjelp. For eksempel ble EXT2fs-biblioteket brukt under overføringen av 4.4 BSD-dumpen og restaureringen av noen verktøy. Svært få endringer var nødvendig for å tilpasse disse verktøyene til Linux (vi måtte erstatte flere filsystem-samvirkende funksjoner med kall til EXT2fs-biblioteket).

EXT2fs-biblioteket gir tilgang til operasjonene til flere klasser. Den første klassen er operasjoner relatert til filsystemet. Ethvert program kan åpne eller lukke et filsystem, lese eller skrive en blokk med biter, eller lage et nytt filsystem på disk. Det er også funksjoner for å manipulere en liste over dårlige blokker i filsystemet.

Den andre klassen av operasjoner fungerer med kataloger. Et program som bruker EXT2fs-biblioteket kan opprette eller utvide en katalog, samt legge til eller slette oppføringer i en katalog. Det er funksjoner for både å bestemme banen til en fil ved hjelp av en inode og å bestemme banen til en fil ved å bruke en spesifisert deskriptor.

Den siste klassen av operasjoner opererer på indekshåndtak. Det er mulig å lese tabellen med beskrivelser, lese eller skrive en beskrivelse og se alle blokkene i den angitte beskrivelsen. Det er mulig å bruke funksjoner for å plassere og frigjøre blokker og deskriptorer.

EXT2fs systemverktøy

Kraftige kontroller er utviklet for EXT2fs-systemet. Disse verktøyene brukes til å opprette, endre og korrigere eventuelle inkonsekvenser i EXT2fs-filsystemer. Mke2fs-programmet brukes til å montere en diskpartisjon som inneholder et tomt EXT2fs-filsystem.

Tune2fs-programmet kan brukes til å konfigurere filsystemparametere Med dets hjelp kan du endre responsen på feil, maksimalt antall systemmonteringer, maksimalt intervall mellom systemsjekker og antall logiske blokker reservert for root-brukeren.

Det kanskje mest interessante verktøyet er filsystemkontrollen. E2fsck er designet for å eliminere inkonsekvenser i filsystemet etter en unøyaktig avslutning av hele systemet. Den første versjonen av e2fsck-programmet er basert på Linus Torvald fsck-programmet for Minix-filsystemet. Den nåværende versjonen av programmet er imidlertid skrevet om ved hjelp av EXT2fs-biblioteket og er raskere og kan rette opp flere feil i systemet når du sjekker det, sammenlignet med originalversjonen.

e2fsck-programmet ble designet for å kjøre med maksimal hastighet. Siden filsystemkontrollprogrammer fører til disklasting, bør e2fsck-algoritmene optimaliseres slik at filsystemstrukturer blir aksessert mye sjeldnere. Og i tillegg vil rekkefølgen for å sjekke inoder og kataloger utføres etter blokknummer for å redusere tiden det tar å flytte diskstasjonhoder.

I første pass kjører e2fsck gjennom alle inoder på filsystemet og undersøker hver inode som et eget systemelement. Dermed blir ikke andre filsystemobjekter sjekket under denne testen. En av hensiktene med slike kontroller er å kontrollere eksistensen av typen fil som kontrolleres, samt korrespondanse for alle blokker i beskrivelsen med blokker med eksisterende tall. Den første passeringen sjekker bitkartene som indikerer bruken av blokker og deskriptorer.

Hvis e2fsck finner datablokker hvis tall er inneholdt i mer enn én deskriptor, kjøres passasjene 1B til 1D for å løse avviket, enten ved å øke blokkene som skal deles eller ved å fjerne en eller flere deskriptorer.

Den første passeringen tar mest tid, siden alle inodene må leses inn i minnet og kontrolleres. For å redusere tiden for I/O-operasjoner i påfølgende passeringer, forblir all nødvendig informasjon i bufferen. Et karakteristisk trekk ved denne ordningen er søket etter alle katalogblokker i filsystemet. For å få denne informasjonen, i den andre omgangen leses deskriptorstrukturene til alle kataloger i filsystemet på nytt.

I det andre passet sjekkes kataloger som separate elementer i filsystemet. Hver katalogblokk kontrolleres separat, uten referanse til andre katalogblokker. Dette lar e2fsck sortere alle katalogblokker etter blokknummer og sjekke dem i stigende rekkefølge, og dermed redusere disktilgangstiden. Katalogblokker testes for å sikre at oppføringene deres er gyldige og at de inneholder referanser til håndtak med eksisterende numre (som bestemt i første pass).

For den første katalogblokken i hver katalogbeskrivelse kontrolleres eksistensen av "."-oppføringer. og "..", og at deskriptornummeret for oppføringen "." samsvarer med gjeldende katalog. (Beskrivelsesnummeret for «..»-oppføringen testes ikke før tredje pass.)

Under den andre passeringen lagres informasjon som tilsvarer den overordnede katalogen i en buffer.

Det skal bemerkes at ved slutten av det andre passet er nesten alle I/O-operasjoner på disken fullført. All informasjon som kreves for den tredje, fjerde og femte passeringen er inneholdt i minnet, men de gjenværende passeringene laster prosessoren og tar opp mindre enn 5-10 % av den totale e2fsck-utførelsestiden.

I den tredje passeringen kontrolleres katalogforbindelser. E2fsck sjekker banene til hver katalog mot roten ved å bruke informasjonen som ble oppnådd under den andre passeringen. Her er ".."-oppføringen for hver katalog sjekket. Alle kataloger som er identifisert etter sjekking og som ikke har en forbindelse med rotkatalogen, plasseres i katalogen /lost+found.

I løpet av firetiden når E2FSCK referansene for hver indeksdeskiptop ved å bruke alle deskiptene og tolkningen av referansene (denne informasjonen er om ettermiddagen) med de innfødte målerne, hvis verdier ble beregnet i resten av det andre og det andre trekket. Alle uopprettede filer med referansetall på null blir også plassert i katalogen /lost+found.

Til slutt, i det femte passet, sjekker e2fsck at all filsysteminformasjon stemmer overens. Her blir bitmaps av blokker og beskrivelser som ble oppnådd i tidligere passeringer sammenlignet med de faktiske verdiene og, om nødvendig, blir informasjonen på disken justert tilsvarende.

Et annet nyttig verktøy er filsystemfeilsøkeren. Debugfs er et kraftig program som lar deg bestemme og angi tilstanden til et filsystem. I hovedsak er det et interaktivt grensesnitt til EXT2fs-biblioteket, det vil si at det oversetter innskrevne kommandoer til kall til bibliotekfunksjoner.

Debugfs kan brukes til å bestemme den interne strukturen til et filsystem, reparere et skadet system manuelt eller lage betingede tester for e2fsck. Dessverre kan dette programmet skade filsystemet hvis du ikke vet hvordan du bruker det. Ved å bruke dette verktøyet kan du ganske enkelt ødelegge filsystemet. Derfor åpner debugfs filsystemet i skrivebeskyttet modus som standard. For å få tilgang i lese-/skrivemodus, spesifiser alternativet -w.

Ytelsesberegning

Bonnie-testresultatene kan sees fra følgende tabell:

Tegn-for-tegn-opptak (Kb/s)

Blokkopptak (Kb/s)

Dubbing (Kb/s)

Avlesning av tegn for tegn (Kb/s)

Blokklest (Kb/s)

BSD Asynkron

BSD Sync

Ext2fs

1237

1033

Xia fs

Resultatene er ganske gode for blokk I/O: EXT2fs-systemet utkonkurrerer andre systemer når det gjelder ytelse. Dette skyldes optimaliseringene som er inkludert i plasseringsprosedyrene. Opptak skjer også ganske raskt, på grunn av at det gjøres i gruppemodus. Den høye lesehastigheten skyldes at blokkene er allokert til filen, slik at stasjonshodene ikke beveger seg mellom to avlesninger og forhåndsleseoptimaliseringen er fullt operativ.

På den annen side har FreeBSD-systemet høyere ytelse for symbolsk I/O. Dette kan skyldes det faktum at FreeBSD og Linux bruker forskjellige prosedyrer for de tilsvarende C-bibliotekene. I tillegg har FreeBSD mest sannsynlig et mer optimert symbolsk lesebibliotek og derfor er ytelsen litt bedre her.

Andrew testresultater

Andrews testresultater kan sees fra følgende tabell:

Passasje 1 Creation

Bestått 2 kopi

Passasje 3 Statussjekk

Bestå 4 byte-for-byte-sjekk

Passasje 5 Samling

2203

7391

6319

17466

75314

BSD Sync

2330

7732

6317

17499

75681

Ext2fs

Resultatene av de to første passeringene viser at Linux vinner med asynkron datautveksling. Når du oppretter kataloger og filer, skriver BSD-systemet kataloghåndtak og katalogoppføringer synkront. Det er spekulasjoner om at asynkron støtte for FreeBSD ennå ikke er fullstendig implementert.

I det tredje passet er verdiene for Linux og BSD veldig like. Mens BSD yter bedre, eliminerer dette problemet ved å legge til en filnavnbuffer til Linux VFS.

I det fjerde og femte passet er Linux raskere enn FreeBSD, hovedsakelig på grunn av bruken av enhetlig bufferadministrasjon. Bufferstørrelsen kan vokse etter behov og ta opp mer minne enn FreeBSD, som bruker en fast størrelse. En sammenligning av resultatene til EXT2fs- og Xia fs-systemene viser at optimaliseringene som er inkludert i EXT2fs faktisk brukes: forskjellen i ytelsen til disse systemene er omtrent 5-10 %.

Konklusjon

EXT2-filsystemet er det mest brukte blant Linux-brukere. Den gir standard Unix-funksjoner og tilleggsfunksjoner. Takket være optimaliseringen som er inkludert i kjernen, viser den dessuten utmerkede ytelsesresultater.

EXT2fs-systemet inkluderer funksjoner som lar deg legge til nye funksjoner. Noen jobber med å utvikle utvidelser til det virkelige filsystemet: Posix ACL, recovery slettede filer og filkomprimering i sanntid.

Først ble EXT2fs-systemet integrert i Linux-kjernen, og nå blir det aktivt portert til andre operativsystemer. EXT2fs er også en viktig komponent i Masix-operativsystemet, som for tiden utvikles av en av forfatterne.


Topp