Denne siden er arkivert, og kan inneholde utdatert, gammel eller feil informasjon.

XMMS-speedup

Problem

xmms over NFS, som bar-PCene vi leverer ut bruker, er treigt:

stat-ing over NFS er treigt, ergo blir det å legge til eller søke etter musikk treigt, siden musikkarkivet vårt er såpass ekstensivt
Lesing av musikktags er tilsvarende treigt

Løsning

Caching.

Ha en locate-lignende database, med hele directory-treet (getdents() for hvert directory, stat() for hver fil) samt metadata (ID3-tags/Vorbiscomment). Ferdig pakket med f.eks. bzip2 (libbz2 er fint, evt. zlib om vi ikke trenger de ekstra prosentene men heller vil spare RAM). Regenereres f.eks. hver natt.
Lag en LD_PRELOAD-ting som kjører før xmms og intercepter kall til open() av directories, getdents() på disse samt stat() (sjekk hva xmms bruker i realiteten av stat64() osv.) på kjente filer. Laster locate-databasen på starten av programmet; evt. stat denne for å sjekke for endringer hvert 10. minutt e.l.. (Kinkig å oppdatere slikt runtime, men det går jo an bare å kille xmms hvis ting har endret seg siden sist e.l. =) ) All informasjon vi kjenner for databasen fra før sendes rett tilbake til xmms fra RAM.
Hack xmms slik at den før den kaller get_song_info heller spør LD_PRELOAD-biblioteket, om det er der. (Bruk ioctl() på en magisk fil eller et nyoppfunnet, reservert syscall for dette.) Dersom det går i orden (dvs. biblioteket har ID3-tags/Vorbiscomments i RAM fra før for den gitte filen), bruk det umiddelbart, hvis ikke, bare la kallet fortsette. Dette krever neppe mer enn 5-10 linjers inngrep i xmms; resten er transparent og håndteres av LD_PRELOAD.

Dette burde redusere de hastighetsproblemene man opplever med flere størrelsesordener, da man slipper å trippe fram og tilbake til NFS-serveren for hver eneste lille stat eller tittel. Ekstrafordel: Vil fungere relativt greit (i hvert fall stat-cachingen) med andre spillere enn xmms om vi skulle ønske det.

Ulemper

Klientene er ikke 100% oppdaterte. Tough luck, arkivet endrer seg relativt seint.
Krever litt mer RAM på klientsiden (RAM er billig, swap er billig), samt `nedlasting' (som i å lese over NFS) av en fil ved start. Skulle jeg fukte fingeren og stikke den i luften ville jeg dog si at dette neppe er snakk om mer enn maksimalt en halv megabyte gitt dagens størrelse på arkivet, men jeg kan ta feil. :-)

Format på cache-db

Kan endres når som helst. Alt er i little endian og høyst plattformspesifikt. :-)

4 bytes magic: "CDB0"

Antall directories cachet (en int, mao. fire bytes)
For hvert directory: antall elementer (en int), directoryets lengde (en int), så navnet på katalogen (ikke nullterminert).
For hvert element i directoryet: filnavnets lengde (en int), så selve filnavnet (ikke nullterminert), så en typebyte (0 = regulær fil, 1 = directory, 2 = noe annet). Dette er faktisk alt vi trenger, siden det er alt xmms bryr seg om. :-)

More to follow (bl.a. ID3-tags/Vorbiscomments). :-)

CVS

Prøv /home/cassarossa/itk/felles/cvs, modulen er "xmms-speedup".

Annet

Patche xmms så den ikke manuelt verifiserer hver eneste lille .ogg-fil på load...

Lenker: Start, gammel dokumentasjon