tusind tak!
poster lige igen for dem der ikke kan gå så langt tilbage.
Jeg går i sving og putter det i produktion på min testmaskine med to
spejlede diske.
// chris
INDIREKTE BLOKKE vs. EXTENTS
ext2 er Linux-udgaven af det traditionelle UNIX filsystem, ufs/ffs. I
modsætning til ufs/ffs laver ext2 ingen antagelser om diskens
geometri. Moderne diske lyver alligevel om cylindre, sektorer, osv.
En inode er en blok i filsystemet, som indeholder information om en
fil: Størrelse, ejerskab, rettigheder, osv. Selve filnavnet er ikke
gemt i inoden, men derimod i det katalog filen bor i. Det er
forklaringen på, at du kan have links i filsystemet, som alle peger på
den samme fil.
ext2 er et såkaldt indirect block based filesystem. Det vil sige at
en fil består af en inode samt nul eller flere datablokke (a 4KB for
ext2 - eller 1KB hvis partitionen er tilpas lille).
Når der ikke er mere plads i inoden til at pege på flere datablokke,
laver man en indirekte blok, som indeholder pointere på flere
datablokke. Og så fremdeles. Så din fil bliver nærmest et træ af
bestående af en inode, nul eller flere indirekte blokke, som peger på
datablokke. Og potentielt indirekte blokke, som peger på indirekte
blokke... Etc.
Man kalder inoder, kataloger og indirekte blokke for metadata.
inoden kaj:
Data blok: 543
Data blok: 234
Indirekte blok: 123
Indirekte blok 123:
Data blok: 533
Data blok: 654
Dvs. kaj består af blok 543, efterfulgt af blok 234, 533 samt 654.
Som du kan se er kaj fragmenteret. Dataene er spredt ud over disken.
I stedet for at bruge blokke ensartede i størrelse benytter IBM JFS
og XFS såkaldte extents. Dvs. blokke af varierende størrelse. Når du
allokerer en fil, bliver den som regel puttet i een stor kontinuerlig
klump på disken. Eller flere større i stykker.
Her er f.eks. min xemacs på XFS. Den er een stor 7.5 MB extent.
(mkp@austin) ~> xfs_bmap `which xemacs`
/usr/local/bin/xemacs:
0: [0..14567]: 15009992..15024559
Dvs. JFS og XFS lider ikke af fragmenteringsproblemer i samme grad som
ext2 (og FAT under DOS).
DATASTRUKTURER
Selve filerne i ext2 er som sagt en slags træer, men ikke brugt på en
måde, som forbedrer opslagshastigheden. Og kataloger, som teknisk set
er filer med lister over inoder, gemmer disse i en lineær liste.
Dvs. slår du en fil op, som starter med Z, buldrer ext2 alle de
foregående filnavne på listen igennem. Hvis du har 10000 filer et
directory, tager det en rum tid at lave opslag.
ReiserFS, JFS og XFS bruger alle binære træer som datastrukturer i
katalogerne i stedet. Dvs. operationer, som involverer kataloger, er
meget hurtigere (Såfremt katalogerne har tilpas mange filer. I den
lave ende er en liste typisk hurtigere end at jonglere et træ...)
De tre sidstnævne filsystemer bruger også træer til at holde styr på
de blokke/extents, som udgør en fil. - I modsætning til ext2s skov af
blokke, som peger på blokke, som peger på blokke...
XFS bruger også træer til at holde styr på fri plads, inoder osv. Og
XFS allokerer inoder dynamisk i modsætning til ext2, hvor du har en
fast øvre grænse på antallet af filer (sættes når du laver
filsystemet).
SPILDPLADS
Som sagt allokerer ext2 alting i 4KB blokke. Dvs. hvis du har en 10
byte fil, fylder den stadig 4KB fysisk på disken.
ReiserFS understøtter tailpacking, hvilket klemmer flere småfiler ind
i halvfyldte blokke. Det sparer plads, hvis man har mange bittesmå
filer.
XFS og JFS runder extents op til 4K ligesom ext2. Så der ryger lidt
plads i svinget der, hvis man har mange småting. Til gengæld spilder
XFS og JFS ikke plads på indirekte blokke ligesom ext2.
JOURNALISERING
Så hvad er ext3? Når man pænt lukker sin maskine ned, skriver Linux
et felt i ext2 filsystemet, som siger, at alt er godt, og vi blev
lukket forsvarligt ned osv.
Hvis det felt ikke er sat, kører Linux en fsck når maskinen booter.
fsck løber alle (anvendte) inodes igennem og checker at datablokkene,
som de peger på, er i overensstemmelse med filsystemets opfattelse af,
hvilke blokke der er i brug. Jo flere filer du har, desto flere
blokke skal fsck løbe igennem. Dvs. det tager en krig.
Det er værd at bide mærke i, at fsck checker filsystemets metadata
igennem, men rører ikke ved selve indholdet af filerne. Hvis du havde
en fil åben, da maskinen crashede, er der stor sandsynlighed for, at
data aldrig nåede at komme fra diskcachen til harddisken. Og
indholdet af den fil kan i givet fald være korrupt. F.eks. hvis kun
halvdelen af alle skrivningerne var færdige, da strømmen gik.
ext3, ReiserFS, JFS og XFS har en journal, hvor de gemmer de
operationer på metadata, som de har tænkt sig at udføre. Når
filsystemet har garanti for, at dataene er fysisk skrevet til
journalen, udfører de operationen på det rigtige sted i filsystemet.
Hvis maskinen crasher i mellemtiden, kan filsystemet checke journalen
når maskinen booter og se ``Oh, vi var ved at omdøbe filen inode 324
fra X til Y. Hedder inode 324 X eller Y? Hvis den hedder X crashede
vi, og vi må heller omdøbe den til Y nu.'' Og så fremdeles indtil
journalen er tom. Dermed har vi garanti for, at filsystemets metadata
er konsistente selvom strømmen gik undervejs. Og vi behøver ikke køre
fsck for at løbe alting igennem.
Selve journalen er som regel ret lille (størrelsesordenen MB), så man
mister ikke meget plads til rigtige data ved at have den.
Ved at have journalen tager det meget kortere tid at checke
filsystemet ved boot. O(journalstørrelse) i stedet for O(antallet af
inoder).
ANDRE TING I GODTEPOSEN
ext2 og XFS understøtter endvidere Access Control Lists, hvilket
betyder, at man kan tildele adgang til filer på brugerbasis. Med
traditionelle UNIX-rettigheder kan du kun tildele rettigheder for
ejeren, gruppen eller alle. Med ACL kan du give Kurt og Knud
læseadgang, mens Rosa har skriveadgang. Det svarer til Access Control
Lists i Windows NT. Og med Samba ovenpå XFS kan du dermed emulere en
NT filserver.
XFS understøtter også DMAPI, som giver mulighed for hierakiske
lagersystemer. Dvs. du kan have 14TB data på bånd men kun 1TB
disk. For brugeren ser det ud som om, alle data er tilgængelige i
filsystemet. Hvis brugeren åbner en fil, som p.t. er på bånd, kalder
DMAPI båndrobotten, som henter den frem. Transparent for brugeren
(bortset fra, at det selvfølgelig tager længere tid, end hvis filen lå
på disk). Og ligeledes kan sjældent brugte filer migreres fra disk
til bånd uden at `forsvinde' fra brugerens syn på filsystemet.
Endelig har XFS support for realtime I/O og Guaranteed Rate I/O (vi
har ikke portet GRIO til Linux endnu). De to giver mulighed for at
sige filsystemet: ``Jeg har en videofilm her, som jeg gerne vil have
afviklet med 40MB i sekundet''. Og GRIO sørger så for, at du får den
nødvendige båndbredde, så din video ikke hakker (forudsat at diskene
kan følge med, naturligvis)
SAMMENLIGNING AF JOURNALISEREDE FILSYSTEMER
ext3 bygger på et solidt gammelt filsystemdesign. Datastrukturerne
var ikke beregnet på så store filer/diske/directories, som vi bruger
nu, så det knirker lidt i hjørnerne. ext3 er bagudkompatibelt med
ext2, og man kan tilføje en journal til ext2 og dermed opgradere til
ext3 uden at formattere om. Dvs. ext3 er rigtig smart, hvis man vil
opgradere sin maskine.
ReiserFS er optimeret til at have mange bittesmå filer i eet stort
katalog, hvilket gør det velegnet til især proxyservere. Men jeg har
ikke mange små filer i mit hjemmekatalog, så min holdning er lidt, at
Reiser er tunet i den forkerte retning. Desuden har jeg ikke den helt
store tiltro til Reisers fejlhåndtering.
IBM JFS er en naturlig forlængelse af ufs/ffs/ext2/ext3 designet, hvor
man har erstattet lineære strukturer med træer og indirekte blokke med
extents. Glimrende filsystem i mellemklassen, men jeg har ikke
hands-on erfaring.
XFS har binære træer, extents, direct I/O, realtime I/O, DMAPI, god
NFS support, delayed allocations og ikke mindst sexappeal. Men det
skal jeg jo sige i mit job :) Med så mange features stiller XFS større
krav til hukommelse på maskinen. Og fordi XFS har masser af heuristik
til at tilpasse sig forskellige belastninger er det også en smule
tungere processormæssigt. Betyder det noget på din Pentium II?
Nixen.
KONKLUSION
Så hvad betyder alt der her journaliseringshalløj for folk med Linux
hjemme i stuen? Hurtigere reboot efter et crash (hvor tit sker det?)
eller strømsvigt (hvor tit sker det?).
Så i praksis ikke ret meget.
ReiserFS, JFS og XFS har alle deres individuelle forcer, alt afhængig
af, hvilken belastning du udsætter dem for. Og er generelt mere
moderne i design end ext2/3. Men på din desktop maskine med en enkelt
disk har det ikke den store effekt.
Til folk med servere som har brug for fancy caching, Samba/NT ACLs,
osv. er der ting at hente. Eller folk med krav om oppetid, som ikke
tillader en halv times fsck efter et crash.
Og så selvfølgelig - Hvis du alligevel opgraderer din maskine, og din
distribution understøtter det, er det dumt ikke at vælge journaling.
Det koster ikke noget.
Eller endelig - Hvis du bare vil fifle med filsystemer, fordi det er
vildt sjovt. Hvilket vil sige alle jer, der har holdt ud at læse 200
linier med teknisk fnidder. Have fun!
--
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com,
http://www.linuxcare.com/ SGI XFS for Linux
Developer,
http://oss.sgi.com/projects/xfs/
> > Jeg skal bruge det til backup af billeder - dvs 100-300 kb filer.
> >
> > er xfs stadig i alfa / beta eller er der noget der bruger det i
> > produktion ?
> >
> For et stykke tid siden postede Martin K. Petersen et grundkursus i
> filsystemer hvor han bla. kikkede på fordele og ulemper ved ext3,
> ReiserFS, JFS og XFS.
>
> Du kan måske hente lidt hjælp til valg af filsystem her:
> Message-ID: <yq1snaqxkbr.fsf@austin.mkp.net>