Agressive disk I/O prefetching algoritmer for Linux

[lath]

Jeg har tænkt mig så småt at begynde at lege med aggressive prefetching algoritmer til Linux styresystemers disk I/O (mere agressivt end ureadahead, som bruges på Ubuntu lige nu).

En morderne HDD kan loade omkring de 150 MB/s hvis den læser sekventielt (=i rækkefølge), men skal den "hoppe" meget rund på harddisken efter data, så kan du godt divdere den hastighed med mindst en faktor 10 på grund af at søgetiden bliver en uforholdsmæssig stor del af ventetiden i et I/O relateret systemkald.

Computere med en SSD er ikke begrænset på samme måde som mekaniske harddiske, og de er derfor ikke målet med algortimerne til agressiv disk I/O prefetching i Linux styresystemer.

Jeg oplever pt omkring 250 KBytes læse hastighed på min Asus Eee (med 2 GB RAM, og en HDD der sekventielt kan læse omkring 60+ MB/s) ved opstart.
Årsagen er at mange inodes(<=ext3), extends(ext4) per fil der er spredt over hele filsystemet.
ext4 er dog god til at minimere antallet af extendts, og det er også selv-defragmenterende, hvis der ellers er rigeligt med fri diskplads i filsystemet.
Styresystemet på min Asus Eee er Xubuntu 14.04.3 LTS, 32-bit på en 1-core Atom CPU med 2 GB fysisk RAM.

Jeg har tænkt mig at implementere det i et FUSE filsystem, der placerer sig imellem programmer i styresystemet, og så det rigtige styresystem.ystemer
Ideelt bør sådan et FUSE filsystem dog i stedet være inde i kernen - i VFS modulet - hvis den skal virke for alle filsystemer.

FUSE filsystemet kigger i /proc filsystemet efter mmap'ede filer.
På den måde kan man indsamle filsystem statistik, og bruge den til at optimere hurtig indlæsning.

readahead systemkaldet, se:

Kode: Vælg alt

man 2 readahead

... vil blive meget brugt.

Hvis du lige tager et kig på output fra:

Kode: Vælg alt

free -m

... så er der øverst til højre noget der hedder cached - det er kernens page cache.

Hvis et program har lov til at bruge readahead(2) systemkaldet, så placerer kernen den fil man har en fildescriptor til inde i cached, så filen er cachet i page cachen (=i RAM).
Det betyder at kernen efter et readahead(2) systemkald - så hurtigt som muligt - placerer(=cacher) filen i fysisk RAM.
Det svarer til at kernen - hvis den var et alm. program - laver et read(2) systemkald, og placerer det den læser fra disken i sin page cache.

Det kunne måske også være interessant at implementere det som en ext4pfs block-device kernel-space driver, hvor pfs i ext4pfs betyder prefetch file system, og ext4 er ext4 filsystemet.

/Lars

[AJenbo]

FUSE vil koste meget på ydelsen af din disk, hvilket jo går i mod målet med dit projekt.

Du kan ikke starte fra et filsystem der fungere via FUSE.

[lath]

FUSE vil koste meget på ydelsen af din disk, hvilket jo går i mod målet med dit projekt.

Jeg er enig i at det er meget dyrt i context switching, men FUSE er godt til koncept testing.

Du kan ikke starte fra et filsystem der fungere via FUSE.

Det er rigtigt at der et problem der idet at init processen ikke er startet op, og at den init process ikke har startet FUSE programmet/servicen op endnu.
Det er nok værd at undersøge om at lave et nyt filsystem (ext4pfs/ext5) i kernel-space er en bedre ide.

/Lars

[lath]

Jeg fandt lige det her diagram over IO stakken i kernen:

https://upload.wikimedia.org/wikipedia/commons/3/30/IO_stack_of_the_Linux_kernel.svg

Det ser ud til at jeg skal lave et filsystem der er Stackable FS (Devices on top of "normal" devices).

/Lars