---

Hej...................

Efter at have rodet lidt rundt i Linux-Mandrake 8.0 får jeg følgende
meddelse efter reboot af PC'en:

/dev/hde9: UNEXPECTED INCONSISTENCY
RUN fsck MANUALLY
(i.e., without -a or -p option)
Failed to check filesystem. Do you want to repair the errors?
(beware, you can loose data)

Kan ikke gøre noget som helst, PC er som låst.
Så må jeg gen-installere Linux-Mandrake 8.0

Er der en anden måde at håndtere dette ovenstående problem.

PÅ FORHÅND TAK.......................!

---

In article <3c0cb76a$0$89841$edfadb0f@dspool01.news.tele.dk>, Iznogood wrote:
> Efter at have rodet lidt rundt i Linux-Mandrake 8.0 får jeg følgende
> meddelse efter reboot af PC'en:
> /dev/hde9: UNEXPECTED INCONSISTENCY
> RUN fsck MANUALLY
> (i.e., without -a or -p option)
> Failed to check filesystem. Do you want to repair the errors?
> (beware, you can loose data)
> Kan ikke gøre noget som helst, PC er som låst.
> Så må jeg gen-installere Linux-Mandrake 8.0

fsck /dev/hde9 , som den foreslå måske?

--
../Jesper Krogh, jesper@linuxpusher.dk
webshop: http://www.linuxpusher.dk

---

Iznogood <lemmiche@mail.dk> wrote in news:3c0cb76a$0$89841
$edfadb0f@dspool01.news.tele.dk:

> /dev/hde9: UNEXPECTED INCONSISTENCY
> RUN fsck MANUALLY
> (i.e., without -a or -p option)
> Failed to check filesystem. Do you want to repair the errors?
> (beware, you can loose data)

Den har jeg også fået. (ligner ihvertfald meget)

> Kan ikke gøre noget som helst, PC er som låst.
> Så må jeg gen-installere Linux-Mandrake 8.0

Så gør det. Løsningen for mig var at lade være med at starte x lige efter
installation. Fx. genstarte et par gange osv.

> Er der en anden måde at håndtere dette ovenstående problem.

Med venlig hilsen Esben.

P.S. Jeg brugte Mandrake 8.1, men det er sikkert samme problem

---

Esben Skov Pedersen <kingesben@12move.dk> writes:

> Iznogood <lemmiche@mail.dk> wrote in news:3c0cb76a$0$89841
> $edfadb0f@dspool01.news.tele.dk:
>
> > /dev/hde9: UNEXPECTED INCONSISTENCY
> > RUN fsck MANUALLY
> > (i.e., without -a or -p option)
> > Failed to check filesystem. Do you want to repair the errors?
> > (beware, you can loose data)
>
> Den har jeg også fået. (ligner ihvertfald meget)

Skriv "yes" for at faa adgang til at logge ind som root.

> > Er der en anden måde at håndtere dette ovenstående problem.

Det kan godt anbefales at bruge et journalling filsystem. Jeg har nu
haft glaede af ext3 i et stykke tid.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

Den 04 Dec 2001 16:58:21 +0100 skrev Thorbjoern Ravn Andersen:
>Esben Skov Pedersen <kingesben@12move.dk> writes:
>
>> Iznogood <lemmiche@mail.dk> wrote in news:3c0cb76a$0$89841
>> $edfadb0f@dspool01.news.tele.dk:
>>
>> > /dev/hde9: UNEXPECTED INCONSISTENCY
>> > RUN fsck MANUALLY
>> > (i.e., without -a or -p option)
>> > Failed to check filesystem. Do you want to repair the errors?
>> > (beware, you can loose data)
>>
>> Den har jeg også fået. (ligner ihvertfald meget)
>
>Skriv "yes" for at faa adgang til at logge ind som root.
>
>> > Er der en anden måde at håndtere dette ovenstående problem.
>
>Det kan godt anbefales at bruge et journalling filsystem. Jeg har nu
>haft glaede af ext3 i et stykke tid.

Ext3 gør ikke fsck unødvendig. Ext3 beskytter kun mod strømsvigt og
"kernel panic", hvor disken ikke bliver unmounted. Er der tale om et
problem på disken (bad sector, vi /etc/hde9, kernel bugs), er en fsck
stadig det eneste der kan redde filsystemet.

Forøvrigt kører fsck faktisk oftere på et korrekt behandlet ext3, end
den gør på et korrekt behandlet ext2. Man har nemlig sat perioden
mellem fsck skal køre alligevel (selvom filsystemet er clean) ned, for
at opdage eventuelle fejl i ext3 tidligere.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/

---

kfr@fleggaard.dk (Kent Friis) writes:

> >Det kan godt anbefales at bruge et journalling filsystem. Jeg har nu
> >haft glaede af ext3 i et stykke tid.
>
> Ext3 gør ikke fsck unødvendig. Ext3 beskytter kun mod strømsvigt og
> "kernel panic", hvor disken ikke bliver unmounted. Er der tale om et
> problem på disken (bad sector, vi /etc/hde9, kernel bugs), er en fsck
> stadig det eneste der kan redde filsystemet.

Jeg har endnu ikke haft mediefejl paa en moderne harddisk. Jeg har
haft harddiske der har staaet totalt af, men ikke nogen med
mediefejl[1]. Intet hjælper mod at smadre filsystemet - enten selv
eller via kernel-fejl, så det synes jeg er lidt langt ude. Kan vi
tillade os at gå ud fra at folk ikke logger ind som root, hvis det er
en arbejdsmaskine, og at vi bare snakker om at strømmen ryger eller
lignende?

> Forøvrigt kører fsck faktisk oftere på et korrekt behandlet ext3, end
> den gør på et korrekt behandlet ext2. Man har nemlig sat perioden
> mellem fsck skal køre alligevel (selvom filsystemet er clean) ned, for
> at opdage eventuelle fejl i ext3 tidligere.

Den har ikke gjort det hos mig endnu, og min Mandrake 8.1 (som jeg
stort set godt vil anbefale) har da tøffet derudaf i et par måneder
snart. Det er en 2.4.8 kerne - jeg har kun prøvet ext3 og ikke nogen
af de andre filsystemer.


[1] Historier fra de gode gamle dage, tæller ikke her. Jeg har
faktisk haft mediefejl på en 286'er engang. Jeg kan ikke huske om det
var en IDE-disk, men jeg tvivler.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

>>>>> "TRA" == Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

>> Er der tale om et problem på disken (bad sector, vi /etc/hde9,
>> kernel bugs), er en fsck stadig det eneste der kan redde
>> filsystemet.

TRA> Jeg har endnu ikke haft mediefejl paa en moderne harddisk.

Alle moderne harddiske reserverer plads til remapping af dårlige
sektorer. Så du ser først mediefejl, når der ikke er flere
reservesektorer at give af. Hvorefter disken er klar til en tur i
skraldespanden.

Jeg får ofte klager over, at nogle filer er langsommere at tilgå end
andre. Og det skyldes i langt de fleste tilfælde, at filen er skrevet
på et område af disken med en eller flere dårlige sektorer. Det
medfører at læsehovedet skal en tur omkring reservesporet for at samle
data op, og derefter tilbage til resten af filen. Og søgninger sløver
ganske alvorligt. Derfor er flere diskproducenter begyndt at sprede
reservesektorerne ud over hele disken i stedet for at have dem
allesammen på indersporet.

De fleste nye diske understøtter S.M.A.R.T., og ved hjælp af
f.eks. smartsuite (nej, ikke fra Lotus) kan du checke status på dine
drev, se hvilke sektorer der er flyttet, osv.

http://www.linux-ide.org/smart.html


TRA> Jeg har haft harddiske der har staaet totalt af, men ikke nogen
TRA> med mediefejl[1].

Sjovt nok er det elektronikken, der fejler hyppigst på moderne diske.
Varmen tager livet af den.

--
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/

---

Martin K. Petersen <mkp@linuxcare.com> writes:

> Alle moderne harddiske reserverer plads til remapping af dårlige
> sektorer. Så du ser først mediefejl, når der ikke er flere
> reservesektorer at give af. Hvorefter disken er klar til en tur i
> skraldespanden.

Det er jeg godt klar over. Jeg har som sagt bare ikke set at de er
blevet brugt op. Derfor er

> http://www.linux-ide.org/smart.html

rigtigt interessant.

I forbindelse med ydelse under Linux, ville det måske være oplagt at
undlade at bruge disse sektorer? Eller lave en fil der ligger der?
Så kan man altid slette den når disken er fuld og bruge de sidste
småtterier.

> TRA> Jeg har haft harddiske der har staaet totalt af, men ikke nogen
> TRA> med mediefejl[1].
>
> Sjovt nok er det elektronikken, der fejler hyppigst på moderne diske.
> Varmen tager livet af den.

Den sidste af slagsen var en quantum som lige holdt 3 dage. Det er så
længe siden at det ikke kan være varmen.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

>>>>> "TRA" == Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

TRA> I forbindelse med ydelse under Linux, ville det måske være oplagt
TRA> at undlade at bruge disse sektorer? Eller lave en fil der ligger
TRA> der? Så kan man altid slette den når disken er fuld og bruge de
TRA> sidste småtterier.

Vi har ikke indflydelse på, hvornår en disk beslutter sig for at
relokere. Man kunne teoretisk lave sammenligning af S.M.A.R.T. data
før og efter en skrivning for at finde ud af, om man er løbet ind i en
dårlig blok. Men det er det ikke værd. Som sagt har moderne diske
reserverne spredt ud over disken med jævne mellemrum, så det har ikke
kæmpe indflydelse på performance længere. Især ikke fordi diskens
elevatorsortering tager højde for dårlige sektorer.


>> Sjovt nok er det elektronikken, der fejler hyppigst på moderne
>> diske. Varmen tager livet af den.

TRA> Den sidste af slagsen var en quantum som lige holdt 3 dage. Det
TRA> er så længe siden at det ikke kan være varmen.

Nå, ja. Skidtet kan jo sagtens være i stykker fra starten af.

--
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/

---

>>>>> "Kent" == Kent Friis <kfr@fleggaard.dk> writes:

>> Det kan godt anbefales at bruge et journalling filsystem. Jeg har
>> nu haft glaede af ext3 i et stykke tid.

Kent> Ext3 gør ikke fsck unødvendig. Ext3 beskytter kun mod strømsvigt
Kent> og "kernel panic", hvor disken ikke bliver unmounted.

Yep. For lige at være pedantisk, så sikrer journaling traditionelt at
filsystemets metadata er konsistente. Indholdet af filer, derimod, er
det stadig op til brugerapplikationerne at udbedre. Dette gælder for
de fleste filsystemer, inklusive ReiserFS, JFS og XFS.

ext3 tillader dog at mounte et filsystem med data journaling, således
at brugerdata også logges. Men det har naturligvis stærk indflydelse
på ydelsen, da data dermed fysisk skal skrives to gange til disken.

Som en mellemløsning tillader ext3 at have filsystemet i ordered mode.
Normalt, når man overskriver en fil, sættes fillængden først til 0 med
truncate(), hvorefter de nye data skrives, og fillængden tilpasses igen.

Med ext3 ordered mode vil truncate(fil, 0), efterfulgt af write(),
efterfulgt af truncate() ignorere det første truncate() kald. En fil,
som lige er blevet overskrevet når et crash forekommer, undgår dermed
at indeholde nuller i stedet for de oprindelige data.

--
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/

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> wrote in
news:kkelmbdlk2.fsf@mimer.null.dk:


> Skriv "yes" for at faa adgang til at logge ind som root.

OK. Hvad kan man egentlig gøre bortset fra at genstarte?

> Det kan godt anbefales at bruge et journalling filsystem. Jeg har nu
> haft glaede af ext3 i et stykke tid.

Det brugte jeg også og jeg fik fejlen alligevel. Hvad er egentlig forskellen
på de forskellige, ext3, reiser osv?

Med venlig hilsen Esben

---

Esben Skov Pedersen <kingesben@12move.dk> writes:

> Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> wrote in
> news:kkelmbdlk2.fsf@mimer.null.dk:
>
>
> > Skriv "yes" for at faa adgang til at logge ind som root.
>
> OK. Hvad kan man egentlig gøre bortset fra at genstarte?

Når du har en #-prompt, kan du køre den fsck-kommando som den
foreslår. Betragt det som scandisk under Windows.

>
> > Det kan godt anbefales at bruge et journalling filsystem. Jeg har nu
> > haft glaede af ext3 i et stykke tid.
>
> Det brugte jeg også og jeg fik fejlen alligevel. Hvad er egentlig forskellen
> på de forskellige, ext3, reiser osv?

Det har jeg ikke nok styr på, til at kunne forklare dig. Jeg ved bare
at formålet er at gøre filsystemet meget mere robust overfor
strømsvigt og lignende.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

Esben Skov Pedersen wrote:

> Det brugte jeg også og jeg fik fejlen alligevel. Hvad er egentlig
> forskellen på de forskellige, ext3, reiser osv?

Uha nu ikke en større kig igen

Ext3 er designet med bagugkompatibilitet med ext2 for øje. Reiserfs er
designet med høj ydelse og pladsudnyttelse for øje.

ext2/3 bruger vist præallokering a pladsen, mens reiserfs allokerer
pladsen efterhånden (det skulle give bedre udnyttelse af pladsen - men
spørg mig ikke hvordan). Ext2/3 bruger en form for tabeller til
indexering af filer/filtræer mens reiserfs bruger træstrukturer.

Ext3's store fordele fremfor reiserfs består i at det er
bagudkompatibelt og at e2fsprogs er et meget stabilt produkt i
modsætning til reiserfsprogs. Til gengæld har reiserfs som sagt ry for
bedre ydelse.

Rasmus

--
-- [ Rasmus 'Møffe' Bøg Hansen ] ---------------------------------------
Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.
-- Alan Cox
--------------------------------- [ moffe at amagerkollegiet dot dk ] --

---

>>>>> "Esben" == Esben Skov Pedersen <kingesben@12move.dk> writes:

Esben> Hvad er egentlig forskellen på de forskellige, ext3, reiser
Esben> osv?

Hold fast! Grundkursus i filsystemer på ca. 200 linier følger...


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/

---

Martin K. Petersen <mkp@linuxcare.com> writes:

> 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).

Mjah, også efter lang tids brug? Det lyder som om at ovenstående
metode lider af samme problemer som malloc-rutiner til C? Nemlig at
hukommelsen let kan blive fragmenteret og at der kan blive behov for
at skubbe rundt på ting for at frigive plads. Hvad nu hvis fx din fil
lå midt på en 20 Mb disk. Så kan der max være en fil på (20-7.5)/2 =
~6 Mb i de to huller.

Fordelen er så at man kan flytte rundt på ting, men så defragmenterer man jo.

> 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).

Jeg arbejdede med SGI maskiner da xfs kom frem, og der var en ... del
problemer. Du lader til at have sat dig ind i tingene - gælder det
også kvaliteten af Linuxporten af xfs?

(Hø, nu så jeg siggen, du burde da vist vide lidt om xfs. Lad endelig høre).
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

>>>>> "TRA" == Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

TRA> Martin K. Petersen <mkp@linuxcare.com> writes:
>> Dvs. JFS og XFS lider ikke af fragmenteringsproblemer i samme grad
>> som ext2 (og FAT under DOS).

TRA> Mjah, også efter lang tids brug?

Det her er min /home partition, som er omkring et år gammel:

(mkp@austin) ~> sudo xfs_db -r /dev/sdb1
xfs_db: frag
actual 392713, ideal 389875, fragmentation factor 0.72%

Det skal lige siges, at jeg har 1 GB mail i Gnus nnml format (een fil
per mail) liggende her. Med autoexpiry på det meste, så en stor del
af filerne slettes efter en måned.


TRA> Det lyder som om at ovenstående metode lider af samme problemer
TRA> som malloc-rutiner til C? Nemlig at hukommelsen let kan blive
TRA> fragmenteret og at der kan blive behov for at skubbe rundt på
TRA> ting for at frigive plads. Hvad nu hvis fx din fil lå midt på en
TRA> 20 Mb disk. Så kan der max være en fil på (20-7.5)/2 = ~6 Mb i
TRA> de to huller.

Korrekt. Ligesom med hukommelse er der ingen filsystemer, der kan
lide at være mere end 90% fulde. Det gælder også for ext2, da
allokatoren ligesom extent-baserede filsystemer forsøger at gemme data
i store klumper. Forskellen er, at ext2 er nødt til at have indirekte
blok pointere for alle blokke, mens XFS kan håndtere `fra blok X til
Y'. Dermed kræver XFS mindre metadata for at holde styr på dataene.

Men det var et sidehop.

XFS allokatoren forsøger at klemme små filer ind i små huller og store
filer ind i store. Som tidligere nævnt holder XFS også styr på fri
plads vha. træer, bl.a. indexeret efter størrelse. Så hvis du gemmer
en 100KB fil, vil XFS forsøge at gemme den i et 100KB hul.

Hvad så når du forlænger filen? Så forsøger XFS igen at finde en
passende extent-størrelse svarende til den ekstra længde.

XFS har en feature, som hedder delayed allocation. I praksis betyder
det, at XFS er meget tilbageholdende med at skrive data til disk.
Sålænge processen skriver, cacher XFS skidtet. Og først når presset
på hukommelsen bliver for stort (eller når vores bdflush pendant synes
at det er tid), sender vi data til disk. På det tidspunkt har vi
derfor en ret god ide om dataenes størrelse og kan vælge et passende
sted. Og på den måde holder vi fragmenteringen nede.

ext2 er ikke nær så smart og gemmer datablokke der, hvor der
tilfældigvis er plads. Og leder så efter næste hul, bruger det, osv.
Så sandsynligheden for fragmentering er meget større.


Det er klart, at man kan tvinge et filsystem i knæ. Jeg skrev engang
et program, som skriver en hel masse bittesmå filer og fjerner hver
anden. Derefter skriver jeg en kæmpe fil, som naturligvis ender med
at blive en gazillion 4KB extents. Og så tumler ydelsen i bund.


TRA> Fordelen er så at man kan flytte rundt på ting, men så
TRA> defragmenterer man jo.

De første mange år shippede XFS uden en defragmenter. Men der viste
sig at være nogle af SGIs kunder, som havde et brugsmønster, der
skurede XFS mod hårene. Så nu har vi xfs_fsr, som kan defragmentere
et live filsystem. Men fsr er ikke særlig brugt, fordi det hører til
sjældenhederne, at XFS filsystemer bliver mere end et par %
fragmenterede.

--
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/