BS
-
13.
März
1998
AKBP-II 1998: Gruppe 7
Audio-CD-Filesystem
Bearbeitet von Bernd Haberstumpf und Timo Weber
Die Aufgabe:
Ursprünglich bestand die Aufgabe darin, ein modular in den Kernel ladbares Filesystem zu erstellen, das es erlaubt, Audio-CD's zu mounten und die darauf enthaltenen Audiotracks als Files im AU-Format zur Verfügung zu stellen. Im Folgenden sollte dem Kernelmodul noch zusätzlich die Fähigkeit verliehen werden, die auf Multi-Mode-CD's vorhandenen Datentracks zu lesen.Unsere Ideen, Probleme und Versuche letztere zu lösen:
Am Anfang war der Kernel...
Zu allererst mußten wir das grobe Gerüst eines ladbaren Kernelmoduls sowie eines Filesystems implementieren, welches sich zuerst nur sicher mounten und unmounten lassen sollte. Dies gab uns genügend Zeit, uns mehr und mehr mit den Funktionen des Kernels vertraut zu machen, und noch vielmehr Zeit, unserer UltraSparc bei Reboots nach einer Flut von Kernelpanics zuzuschauen.SCSI-Commands und "Was ist eigentlich auf der CD?"
Als die anfänglichen Probleme überwunden waren, kümmerten wir uns endlich um das CD-Rom-Laufwerk und den Inhahlt der CD's. Zunächst mußte der Typ des Laufwerks(INQUIRY) und anschließend der Table Of Contents (READ_TOC) bestimmt werden. Als das geschehen war konnten die V-Nodes für die Tracks generiert werden, und somit war dann, nach Erstellung einiger anderer Funktionen, der Zugriff auf die Tracks prinzipiell möglich. Alles in allem mußten wir festellen, daß das Absetzten der diversen SCSI-Commands mit einigen Problemen behaftet war. Im großen und ganzen beschränkten wir uns darauf, uns bei fertigen Lösungen mittels Copy and Paste zu bedienen.Kopieren und Abspielen eines Tracks auf einmal?
Bevor wir uns diesem frommen Wunsch widmen konnten, mußten wir uns ersteinmal darum kümmern, daß sich das Abspielen eines Tracks allein vernünftig anhörte. Das uns zur Verfügung gestellte Toshiba-Laufwerk hatte nämlich so seine liebe Mühe mit dem neu Aufsetzen, was sich durch häßliche Knackser beim Abspielen von CD bemerkbar machte. Doch nach der Einführung eines Caches (siehe unten) war dieses Problem behoben.Glücklicherweise erwies sich dieser Cache mit gegeigneter Konfiguration als gut genug, um einen Track von CD abzuspielen und gleichzeitig einen Audiotrack auf Festplatte zu kopieren, ohne nennenswerte Qualitätsverluste beim Hören hinnehmen zu müssen.
Was tun mit Datentracks?
Das Problem mit den den Datentracks ist folgendes: Das Laufwerk muß für Audio- und Datentracks verschiede Blockmodes fahren (Audio 2352 Bytes, Data -bei uns- 2048 Bytes). Das wiederum hat zur Folge, daß verschiedenartige aktive Read-Threads sich gegenseitig den Blockmode verstellen können. So kann es hin und wieder passieren, daß ein Data-Read-Thread (oder Audio-Read-Thread) seinen Blockmode einstellt, wärend ein Audio-Read-Thread (oder Data-Read-Thread) gerade beginnen will zu lesen, d.h. dann im falschen Blockmode. Darauf reagiert der Kernel immer panisch!Deshalb haben wir uns entschlossen, die anstehendne verschiedenartigen Read-Requests jeweils in einer Queue zu halten und einen Scheduler (siehe unten) entwickelt, der mit Hilfe von Condition-Variables entscheidet, welcher Thread jetzt darf und welcher nicht.
Leider war es aber nicht möglich, auch reibungsfrei Datentracks zu kopieren und dabei Audiotracks vernünftig abzuspielen, da der Blockmode-Wechel scheinbar zu viel Zeit beansprucht, und dies von unserem Cache nicht abgefangen werden kann.
Die Funktionen unseres Moduls:
Der ominöse Cache
Um die CD Zugriffe zu minimieren und das Wohlbehagen beim Abspielen zu maximieren, implementiert das Audiofilesystem einen Buffercache im klassischen Sinne mit einstellbarer Cachesize- und Kachelgröße.Um kontinuierliche Zugriffe zu bevorzugen wird ein Roundrobin Fifo 5 Chances Priority Sheduling für die letzten Blöcke eines Lesezugriffs gefahren.
Jede Lesezugriff wird immer zuerst in den Cache geschrieben. Sind keine freien Cache Seiten vorhanden, wird nach der FIFO Strategie der Puffer wieder freigegeben der schon am laengsten im Cache ist.
Die letzte Seite die bei einem Read gelesen wird bekommt allerdings eine höhere Priorität von 5. Stoöst der Freigabemechanismus bei der Freigabe von Seiten auf eine so priorisierte Seite, so bekommt diese Seite nochmal eine Chance mit einer um 1 verminderten Priorität.
Der Scheduler
Die Funktionsweise des Schedulers orientiert sich an zwei Marken. Zum einen soll eine bestimmte Anzahl von gleichartigen aktiven Threads nicht überschritten werden, und andererseits soll nach der Abarbeitung einer bestimmten Anzahl von gleichartigen Threads ein Umschalten des Blockmodes erfolgen, damit andersartige Read-Threads auch zum Zug kommen können. Führt man für Audio- und Data-Read-Threads verschiedene Marken ein, so läßt sich sogar eine (eingeschräkte) Priorisierung bestimmter Requests erreichen.Der Versuch, hier die genaue Funktionsweise in Worte zu fassen, würde den Rahmen sprengen...
Das Mount-Kommando
Das Mount-Kommando hat die Form:
mount -F aufs [-o user='username',group='groupname',mode='mode'(octal),nblocks='num',nframes='num',ncaches='num'] devicename mountpoint
Mit user, group und mode lassen sich Besitzer, Gruppe und Zugriffsrechte auf die Tracks einstellen. Default: user=root, group=wheel, mode=444 Mit nblocks, nframes und ncaches wird der Cache konfiguriert. Default: nblocks=26, nframes=26, ncaches=16 (ausreichend für Abspielen und Kopieren zugleich)