← Back to team overview

sslug-teknik team mailing list archive

Re: Hvilket filsystem?

 

Mogens Melander wrote:
----- Original Message -----
From: "Michael Rasmussen" <mir@xxxxxxxxx>
Newsgroups: sslug.teknik

På en desktop kan det reelt set være hip som hap, hvad du vælger. Du
vil næppe i daglig brug komme i en situation, hvor du vil opleve nogen
mærkbar forskel - her undtaget ext2.

De filsystemer, der har breddest tilslutning, er de nævnte af Peter.


Hvad er der galt med ext2 ?

Siden du spoerger: Rigtigt meget.

Et filsystem har (grundliggende) 2 typer data paa sig: Data og meta-data. Meta-data er alle de data, der har med directory-strukturer, permissions, etc at goere. Resten er selve filernes indhold. ext2 benytter sig af en asynkron meta-data politik. Dette er i modsaetning til BSD'ernes UFS, der har en synkron meta-data politik (uden softupdates, som Peter naevnte).

Det problem vi er bange for er foelgende scenario:

1. Vi vil gerne skrive en fil til disken og vaelger at oprette filen i directory meta-dataen foerst hvorefter vi peger filen mod de blokke der efterfoelgende skal skrives med selve filens indhold.

2. Stroemmen gaar.

Nu er din disk inkonsistent. Du har et problem som en fsck maaske kan afhjaelpe, men i de fleste tilfaelde har du bare tabt.

I en synkron meta-data politik skrives filens indhold altid foer filen oprettes i directory-strukturen. Hvis stroemmen gaar kan du ''bare'' loebe hele disken igennem for allokeret data der ikke har en directory-reference og smide det over som fri plads paa disken. Dette er hvad fsck paa BSD'ere goer.

I en asynkron meta-data politik tillader du 1. i ovenstaaende med en mulig 2. til foelge. Det er grundliggende p*ssefarligt. Hvorfor ext2 koerer med asynkrone meta-data updates skyldes 2 ting:

* synkrone meta-data operations er hamrende langsomt.
* Med mindre du har et SCSI Hardware RAID med Battery-backup paa write-cachen har du alligevel tabt med synkrone updates. Disken lyver simpelthen omkring skrivninger og melder dem fuldfoert saa snart data ligger i cachen. Et stroemudfald kan da tage livet af diskens konsistens. Harddiskcontrollere goer det her for at vinde hastighed mod sikkerhed. Det kan ioevrigt slaas fra, men diskhastigheden lider meget under det ved skrivninger. Imidlertid er det en noedvendighed hvis man har sine data kaert.

Journaliseringen fra ext3 eliminerer dette problem og saa kan disken koeres asynkront paa meta-data. Problemet er bare at Write-ahead-loggen tager tid at skrive og dermed tabes der hastighed. Med write-cache slaaet til er sikkerheden ogsaa vaek (medmindre der er batteri paa write-cachen og du kan faa disken op indenfor kort tid, eller at du har en UPS paa disken/maskinen).

BSD'erne har en funktion kaldet softupdates, der kort fortalt samler flere meta-data operationer i een. Operationerne lagres i RAM og smides saa til disk i grupper. Kompleksiteten fremkommer af, at hvis en blok ikke er skrevet indenfor 30 sekunder, saa skal den til disk.. NU!.... Saa sker der et temporaert rollback af alle andre writes, blokken skrives og et roll-forward re-apply'er alle de resterende operationer.

Konsekvensen er at en softupdated disk kan koere voldsomt hurtigt fordi meta-data operationer samles i klumper. Til gengaeld er prisen at du kan tabe op til 30 sekunders data (disken honorerer stadig fsync()-kald korrekt, saa sikkerhed kan opnaas hvis man oensker det). Et andet vaesentligt problem med softupdates er at du under reboots bliver noedt til at foretage et dyrt (lang-tids) fsck, fordi du ikke har en journal paa disken at stoette dig til (Se Peters mail).

FreeBSD har et trick, hvor de tager et snapshot af disken, koerer videre og fsck'er disken i baggrunden naar systemet er oppe. Dette giver hurtige boots, men det koster jo saa efterfoelgende i performance indtil diskene er faerdig-checkede.

OpenBSD-folkene har en rimeligt fed ide med at koere journalisering ovenpaa softupdates, men det er desvaerre ikke blevet til noget endnu. Man faar en meget simpel journal med de garantier som softupdates giver en. FreeBSD er igang med at implementere journaling paa UFS fordi det lader til at vaere den bedste maade at koere diske paa.

---

Der findes dog et sted hvor en ext2-disk er at foretraekke: Data som du alligevel kan genskabe rimeligt hurtigt og hvor hastighed paa disken er vigtigt: /tmp, data-mining scratch areas, source-build-areas, etc er kandidater. De faar simpelthen et mk_ext2fs under boot!

---

Min personlige preference er ext3 paa linuxsystemer: Old. Proven. Stable.


References