BS - Mar. 13, 1998

AKBP-II 1998: Gruppe 1

Loopback Device Treiber

Grundprinzip

Das Loopback Device stellt Dateien als Devices zur Verfügung. Es ermöglicht es zum Beispiel, ein CD Disk Image, das sich auf einer Festplatte befindet, als CD zu mounten. Sinnvoll ist dies zum Beispiel, wenn man von CD-Brenner-Software erzeugte Images vor dem Brennen testen möchte. Es ist grundsätzlich möglich, jede Art von Dateisystem aus dem Disk Image mit Hilfe des Loopback Devices zu Verfügung zu stellen, das man auch so mouten könnte.
Die folgende Zeichnung illustriert das Verfahren am obigen CD-Beispiel:

Im dargestellten Beipiel befindet sich ein CD image im High Sierra Format (hsfs) auf der Festplatte, welche mit ufs formatiert ist. Wenn das Loopback Device (loop) auf genau dieses CD image gelinkt ist, kann ein Prozess darauf zugreifen, als handele es sich direkt um ein High Sierra Filesystem. Die "Zwischenschicht" des Platten-ufs bleibt transparent.

Device Instanzen und "Links"

Welche Disk Images über welche Device-Instanzen angesprochen werden, hängt davon ab, wie die Device-Instanzen "gelinkt" sind. Bei der Installation des Treibers werden eine Anzahl Instanzen unter /dev angelegt. Deren Namen können frei gewählt werden (z.B. /dev/loop0, /dev/loop1 etc.). Die Bindung zwischen Device und Treiber erfolgt über die Major- (und Minor-) Number. Die dem Treiber zugeordnete Major-Number ergibt sich aus dem Eintrag in /etc/name_to_major. Die Minor-Number ist die Nummer der Instanz. Instanz-Nummern sollten ab 0 und ohne Lücken vergeben werden.

Jeder Instanz kann nun mit Hilfe des von uns implementierten Tools loplk (UNIX für loop link) eine Datei zugeordnet werden. Sinnvollerweise sollte diese Datei ein Disk Image sein, auch wenn das nicht verpflichtend ist. Das Kommando zum Linken sieht etwa so aus:

    $ loplk -link /usr/tmp/128kfs /dev/loop0r

Für jede Instanz gibt es ein character (raw) device und ein block device. Zu Beachten ist, daß der Link nur vom raw device aus erzeugt werden kann. Überhaupt arbeitet loplk nur mit raw devices, weil es sich bei der Kommunikation mit dem Treiber des ioctl() Systemaufrufs bedient. Den oben erzeugten Link könnte man beispielsweise mit folgendem Kommando wieder aufheben:

    $ loplk -unlink /dev/loop0r

Der Loopback Device Treiber stellt zu jedem Zeitpunkt sicher, daß sich die Devices in einem konsistenten Zustand befinden. Es ist also unmöglich, einen Link aufzuheben, der gerade benutzt wird, das Treibermodul aus dem Speicher zu entfernen, wenn noch Devices in Benutzung sind und ähnliches mehr. Das dritte und letzte von loplk bereitgestellte Kommando dient der Ausgabe des aktuellen Status aller Devices:

    $ loplk -info /dev/loop0r
     0 -> "/usr/tmp/128kfs" (busy, pid: 542)
     1 -> "/usr/tmp/rootfs"
     2 -> (not linked)
     3 -> "/proj/i4akbp_ii/image-files/AKBP_CD.img" (busy, pid: 533)
     4 -> (not linked)

In diesem Beispiel sind die Instanzen 0, 1 und 3 aktiv. Bei den Devices, die aktuell busy sind, wird noch die pid des Prozesses angezeigt, der das Device gerade belegt hat.

Mounten von Disk-Images

Um konkret ein Disk-Image zu mounten, muß zunächst der Link mit Hilfe des oben beschriebenen Tools loplk erstellt werden. Dann kann das Device durch das mount-Kommando gemountet werden. Im folgenden Beispiel wird ein CD Disk Image verfügbar gemacht:

    $ loplk -link /proj/i4akbp_ii/image-files/AKBP_CD.img /dev/loop1r
    $ loplk -info /dev/loop1r
     0 -> (not linked)
     1 -> "/proj/i4akbp_ii/image-files/AKBP_CD.img"
     2 -> (not linked)
     3 -> (not linked)
     4 -> (not linked)
    $ mount -F hsfs -r /dev/loop1 /mnt
    $ loplk -info /dev/loop1r
     0 -> (not linked)
     1 -> "/proj/i4akbp_ii/image-files/AKBP_CD.img" (busy, pid: 434)
     2 -> (not linked)
     3 -> (not linked)
     4 -> (not linked) 
    $ cd /mnt
    $ ls
    MiB.zoo              fpu/                 rwlock.h
    acct.h               frame.h              rwlock_impl.h
    acl.h                fs/                  sad.h
    ...

Zu beachten ist, daß das mount-Kommando auf dem Block-Device arbeitet. In der Beispiel-Konfiguration sind die raw devices von den zugehörigen Block Devices dadurch unterschieden, daß sie ein zusätzliches 'r' (für raw) im Namen tragen. Die Parameter des mount-Kommandos legen hier fest, daß ein High Sierra File System gemountet werden soll, und zwar read-only. Würde z.B. ein ufs gemountet, wären auch Schreibzugriffe erlaubt. Die pid ist die pid des mount-Prozesses, hat also in diesem Fall eher symbolischen Wert. :-)

Erzeugen von Dateisystemen

Als weitere Anwendung für den Loopback Device Treiber wäre denkbar, File System Images zu erzeugen, z.B. für Boot-Disketten. Dies ist in der folgenden Beispiel-Session dargestellt:

    $ id
    uid=0(root) gid=1(other)
    $ mkfile 128k /usr/tmp/fs128k 
    $ loplk -link /usr/tmp/fs128k /dev/loop3r
    $ loplk -info /dev/loop1r
     0 -> (not linked)
     1 -> "/proj/i4akbp_ii/image-files/AKBP_CD.img" (busy, pid: 434)
     2 -> (not linked)
     3 -> "/usr/tmp/fs128k"
     4 -> (not linked)
    $ mkfs -F ufs -o nsect=32,ntrack=16,bsize=8192,fragsize=1024,cgsize=2,
         free=0,rps=60,nbpi=2048,opt=t,apc=0,gap=0,maxcontig=7 /dev/loop3r 256
    /dev/loop3r:    256 sectors in 1 cylinders of 16 tracks, 32 sectors
                    0.1MB in 1 cyl groups (2 c/g, 0.50MB/g, 128 i/g)
                    super-block backups (for fsck -F ufs -o b=#) at:
                    32,
    $ fsck -F ufs /dev/loop3
    ** /dev/loop3
    ** Last Mounted on /
    ** Phase 1 - Check Blocks and Sizes
    ** Phase 2 - Check Pathnames
    ** Phase 3 - Check Connectivity
    ** Phase 4 - Check Reference Counts
    ** Phase 5 - Check Cyl groups
    2 files, 9 used, 70 free (14 frags, 7 blocks, 17.7% fragmentation)
    $ mount -F ufs /dev/loop3 /mnt_test
    $ cd /mnt_test
    $ ll
    total 16
    drwx------   2 root        8192 Mar 12 18:20 lost+found/
    $

Zunächst wird eine leere Datei der Größe 128 KB erzeugt (unser Treiber unterstützt keine wachsenden Devices), die dann mit einer Device-Instanz verlinkt wird. Der mkfs-Aufruf erzeugt auf der leeren Datei das Disk Image. Die Parameter sind hier möglicherweise suboptimal gewählt. Nachdem das neue Image nach /mnt_test gemountet wurde, kann man wie auf eine Festplatte mit read/write Operationen darauf zugreifen.

Ausblick

Features, die man sich vielleicht noch wünschen würde, die aber aus Zeitgründen nicht mehr implementiert werden konnten, sind:

Der Device Treiber sollte auf ioctls reagieren können, die die Plattengeometrie anfragen. Eine Pseudo-Plattengeometrie müsste simuliert werden.
Durch eine zusätzliche Zeile Code könnte auf ein eject ioctl reagiert werden, das dann die Unlink-Semantik nachbildete. Wir haben uns dagegen entschieden, weil kein passendes Äquivalent zum Linken gefunden werden konnte.

Thomas Jensen <tsjensen@cip>, Oliver Podszun <orpodszu@cip>

About our Server | Mail to Webmaster | Navigational Hints | Search