From: "Jesper Louis Andersen" <none@jlouis--mongers.org.lh.bsd-dk.dk> Date: Fri, 28 Jan 2005 02:07:05 +0100 To: bsd-dk@bsd-dk.dk Subject: Re: SATA NCQ vs. filsystemer (soft updates)
Quoting Michael Knudsen (e@molioner.dk):
> nu har jeg hoert en hel masse snakke om NCQ og om, hvor smart det er. I
> den forbindelse er jeg lidt i tvivl om, hvor smart det er i forhold til
> integritet paa filsystemer, saa jeg lurede lidt paa, om nogen kan opklare
> det lidt for mig.
Well, det betyder bare at du kan smide flere requests til harddisken
og faa svar, naar de enkelte requests completer. Du ved ikke i hvilken
raekkefoelge de completer, akkurat som du har sagt. NCQ ser ikke ud
til at have en ordning i hardwareimplementationen, saa det maa dit
OS holde styr paa. Med andre ord maa du lave synkron I/O paa kritiske
operationer. Men - du kan stadig lave mange ting i parallel. Skriver
du eksempeltvist 3 (nye) filer kan du foerst issue en masse kommandoer
til at fylde filerne med data. Naar de saa alle er completed issuer
du 3 kald til directory-noderne. Hvis systemet saa kun naar at skrive
nogle af de sidste 3 requests, saa er du stadig sikker paa et
konsistent filsystem.
Now, enter softupdates. Du har stadig den samme ordning, men nu bliver
dine meta-dataoperationer delayed, saa de kan naa at akkumulere flere
operationer, foerend de skrives. Igen garanteres der integritet af
filsystemet (modulo 30 sekunder, eller hvad din syncer er sat til).
Dette sker via samme ide som foer: Ordning af skrivninger. Du kan
derfor lave det samme som ovenstaaende her igen.
Som det er nu, forestiller jeg mig en queue i kernen, der holder
enkelte requests. Du sender nu bare requests til disken via tagged
command queueing -- Men for hver afhaengig request der naar forenden
af din queue, har du et reference count paa hvor mange der afhaenger
af den, som ikke er issuet endnu, eller ligger og venter paa completion.
Du hiver den saa af din queue, men issuer den ikke. Efterhaanden
som dens afhaengigheder completer, falder ref-counteren og naar den
naar 0, saa issuer du operationen og rydder op. Afhaengighederne kan
findes via et O(n) traverse af din issue queue naar din afhaengige
request skubbes paa queue foerste gang. Alternativt er det nok muligt
at goere det i O(1) tid, fordi du har afhaengighedsinformationen
tilgaengelig i kernen.
Jeg ved dog ikke om BSD'erne laver ovenstaaende -- eller noget
endnu smartere.
-- jlouis
This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:24:47 CET