-
Die
Erfindung betrifft allgemein das technische Gebiet der Dateisysteme
und insbesondere die Organisation eines Dateibaums bei einem tragbaren Datenträger.
-
Ein
tragbarer Datenträger
im Sinne des vorliegenden Dokuments kann insbesondere eine Chipkarte
(smart card) in unterschiedlichen Bauformen oder ein Chipmodul oder
ein sonstiges ressourcenbeschränktes
System sein. Typische Gegebenheiten bei tragbaren Datenträgern sind
die erhebliche Beschränkung
von Speicherplatz und Rechenleistung sowie die Forderung, daß auch nach
einem plötzlichen
Ausfall der Versorgungsspannung – z.B. durch Trennen des Datenträgers von
einem Terminal – keine
undefinierten Betriebszustände
auftreten dürfen.
-
In
einem internen Forschungsprojekt der Giesecke & Devrient GmbH wird gegenwärtig untersucht,
inwieweit ein UNIX®-artiges Betriebssystem auf
einem heute verfügbaren
oder in Zukunft zu erwartenden Datenträger implementiert werden kann. In
diesem Zusammenhang ist insbesondere eine Implementierung des unter
der Marke Linux® bekannten Betriebssystems
vorgesehen. Das Buch "Understanding
the Linux Kernel" von
D. P. Bovet und M. Cesati, O'Reilly
Verlag, 2. Auflage, Dezember 2002, enthält eine detaillierte technische
Beschreibung dieses Betriebssystems.
-
Die
bei dem Linux-Betriebssystem üblicherweise
eingesetzten Dateibäume,
Dateisysteme und Dateisystem-Organisationstechniken sind insbesondere
auf den Seiten 12–16
sowie in den Kapiteln 12, 15 und 17 des gerade zitierten Buches
erläutert.
Auf diese Fundstellen wird Bezug genommen. Es ist dort jedoch weder
ein Einsatz des Linux-Betriebssystems für tragbare Datenträger noch
eine spezielle Anpassung von Dateisystemen an die Gegebenheiten
bei tragbaren Datenträgern
offenbart.
-
Die
Erfindung hat daher die Aufgabe, eine Technik zur Organisation eines
Dateibaums bereitzustellen, die speziell auf die Gegebenheiten bei
tragbaren Datenträgern
zugeschnitten ist. Gemäß einem ersten
Aspekt soll die Erfindung insbesondere dazu beitragen, mit geringem
Aufwand undefinierte Betriebszustände zu verhindern. Gemäß einem
zweiten Aspekt soll die Erfindung die technischen Grundlagen für eine besonders
speicherplatzsparende und/oder leistungsfähige Dateiverwaltung in dem tragbaren
Datenträger
liefern.
-
Erfindungsgemäß wird diese
Aufgabe ganz oder zum Teil gelöst
durch ein Verfahren gemäß Anspruch
1 bzw. Anspruch 6, einen tragbaren Datenträger gemäß Anspruch 12 bzw. Anspruch
13 sowie ein Computerprogrammprodukt gemäß Anspruch 14. Die abhängigen Ansprüche betreffen
bevorzugte Ausgestaltungen der Erfindung.
-
Die
Erfindung geht von der Grundüberlegung aus,
die an sich bekannte Technik des Einbindens von Dateisystemen in
einen Dateibaum in einer für tragbare
Datenträger
besonders vorteilhaften Weise zu nutzen. Unter dem im vorliegenden
Dokument verwendeten Begriff "Dateibaum" ist insbesondere
jede hierarchische Struktur zu verstehen, die Verzeichnisse und
Dateien aufzunehmen vermag. Dies schließt nicht aus, daß im Dateibaum
weitere Elemente vorhanden sind, z.B. Querverweise (links) oder
Gerätedateien
(device files). Wenn im vorliegenden Dokument ein Dateisystem als
in den Dateibaum eingebunden (mounted) bezeichnet wird, soll dies
nicht notwendigerweise heißen,
daß das
Dateisystem nur einen Teil des Dateibaums darstellt. Im Extremfall kann
als Ergebnis des Einbindens auch der gesamte Dateibaum von dem Dateisystem
gebildet werden.
-
Gemäß einem
ersten Aspekt der Erfindung wird zumindest ein transaktionsbasiertes
Dateisystem in den Dateibaum eingebunden. Bei einem solchen Dateisystem
werden Dateioperationen zumindest zum Teil wie atomare Transaktionen
behandelt. Wenn während
einer Dateioperation die Versorgungsspannung des Datenträgers ausfällt, werden undefinierte
Zwischenzustände
des Dateisystems spätestens
beim nächsten
Hochfahren des Datenträgers
wieder rückgängig gemacht.
Insgesamt werden also Aufgaben der Transaktionssicherung zumindest zum
Teil vom Dateisystem übernommen.
Anwendungsprogramme, die von dem Datenträger ausgeführt werden, brauchen diese
Aufgaben dann nicht mehr selbst zu erledigen. Dies erleichtert die
Programmierung, erhöht
die Sicherheit des Datenträgers und
führt in
der Regel zu einem deutlichen Effizienzgewinn.
-
Gemäß einem
zweiten Aspekt der Erfindung sind in den Dateibaum mindestens zwei
in unterschiedlichen Technologien ausgestaltete Dateisysteme eingebunden,
die zumindest zum Teil – und
in bevorzugten Ausgestaltungen überwiegend
oder vollständig – zur Speicherung
mindestens eines Anwendungsprogramms bzw. zur Speicherung von Nutzdaten
für das
mindestens eine Anwendungsprogramm dienen. Diese Lehre ermöglicht eine
besonders vorteilhafte Kombination der Eigenschaften unterschiedlicher
Dateisysteme. So kann beispielsweise für das mindestens eine Anwendungsprogramm
ein einfaches, speicherplatzsparendes Dateisystem verwendet werden.
Für die
Nutzdaten wird dagegen in bevorzugten Ausgestaltungen ein leistungsfähiges und/oder
transaktionsbasiertes Dateisystem verwendet.
-
Vorzugsweise
ist das transaktionsbasierte Dateisystem ein journalführendes
Dateisystem (journaling file system). Solche Dateisysteme sind z.B. unter
den Namen Ext3fs, ReiserFS, XFS und JFS an sich bekannt. Bei journalführenden
Dateisystemen werden die in das Dateisystem zu schreibenden Datenblöcke zunächst in
ein Journal aufgenommen. Erst wenn dieser Vorgang erfolgreich abgeschlossen ist,
erfolgt das eigentliche Schreiben in das Dateisystem. Tritt während des
Schreibens in das Journal eine Betriebsunterbrechung auf, so werden
beim nächsten
Hochfahren des Datenträgers
die Einträge im
Journal verworfen. Erfolgt die Betriebsunterbrechung dagegen erst,
wenn der Schreibvorgang in das Journal vollständig abgeschlossen ist, so
werden beim nächsten
Hochfahren des Datenträgers
die Einträge
aus dem Journal in das Dateisystem übertragen.
-
Besonders
bevorzugt wird ein Betriebsmodus des journalführenden Dateisystems verwendet, in
dem nicht nur Metadaten, sondern alle in das Dateisystem zu schreibenden
Datenblöcke
in dem Journal aufgezeichnet werden. Ein derartiger Betriebsmodus
bietet eine vollwertige Transaktionssicherung, die garantiert, daß eine Schreiboperation entweder
vollständig
ausgeführt
oder rückstandsfrei abgebrochen
wird. In manchen Ausgestaltungen werden dagegen journalführende Dateisysteme und/oder
Betriebsmodi verwendet, die nur Metadaten, nicht aber die eigentlichen
Inhalte, in dem Journal aufzeichnen. In diesem Fall wird bei einer
Betriebsunterbrechung nur die Konsistenz der Strukturen des Dateisystems,
nicht aber die Konsistenz der gespeicherten Dateien, gewährleistet.
Vorzugsweise sollen auch derartige Ausgestaltungen als "transaktionsbasierte
Dateisysteme" angesehen
werden.
-
In
vorteilhaften Ausgestaltungen wird das mindestens eine Anwendungsprogramm
nicht in einem transaktionsbasierten Dateisystem gespeichert. Vielmehr
ist für
solche Nutzdaten vorzugsweise ein einfaches, speichersparendes Dateisystem
vorgesehen, beispielsweise eines der unter den Namen Minix-FS und
Flash-FS an sich bekannten Dateisysteme.
-
In
bevorzugten Ausführungsformen
wird ein Anwendungsprogramm-Dateisystem
zur Speicherung der Nutzdaten des mindestens einen Anwen dungsprogramms
simuliert. Aus Sicht des Anwendungsprogramms kann das Anwendungsprogramm-Dateisystem
eine bei tragbaren Datenträgern übliche Struktur,
beispielsweise nach ISO/IEC 7816-4, aufweisen. Diese Struktur wird
in manchen Ausgestaltungen in dem Dateibaum des Datenträgers beibehalten.
Vorzugsweise ist jedoch vorgesehen, daß das Anwendungsprogramm-Dateisystem
in eine einzige Container-Datei oder einige wenige Container-Dateien
des Dateibaums abgebildet wird. Zugriffe des Anwendungsprogramms
auf eine Datei des Anwendungsprogramm-Dateisystems werden dann in entsprechende
Zugriffe auf einen mit der Datei korrespondierenden Abschnitt der
Container-Datei abgebildet.
-
Wie
eingangs bereits erwähnt,
weist der Datenträger
vorzugsweise ein UNIX-artiges Betriebssystem auf. In bevorzugten
Ausgestaltungen wird mindestens ein aus dem Linux-Betriebssystem
an sich bekanntes Dateisystem in geeignet modifizierter Form eingesetzt.
Die Erfindung kann jedoch auch für andere
Betriebsysteme eingesetzt werden, bei denen ähnliche Gegebenheiten vorliegen.
Insbesondere ist es vorteilhaft, wenn das Betriebssystem einen Mechanismus
zum Einbinden unterschiedlicher Dateisysteme in einen Dateibaum
aufweist. Ein solcher Mechanismus ist bei dem Linux-Betriebssystem als
VFS (virtual filesystem switch) an sich bekannt.
-
Der
erfindungsgemäße Datenträger ist
gemäß einem
ersten Aspekt dazu eingerichtet, ein erfindungsgemäßes Verfahren
zur Organisation eines Dateibaums auszuführen. Gemäß einem zweiten Aspekt enthält der Datenträger einen
Dateibaum, der durch ein erfindungsgemäßes Verfahren generierbar ist
oder generiert wurde. In bevorzugten Ausgestaltungen weisen der
Datenträger
und/oder das Computerprogrammprodukt Merkmale auf, die den oben beschriebenen
und/oder den in den abhängigen
Verfahrensansprüchen
genannten Merkmalen entsprechen.
-
Das
erfindungsgemäße Computerprogrammprodukt
kann ein körperliches
Medium mit gespeicherten Programmbefehlen sein, beispielsweise ein
Halbleiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerprogrammprodukt
kann jedoch auch ein nicht-körperliches
Medium sein, beispielsweise ein über
ein Computernetzwerk übermitteltes
Signal. Insbesondere kann das Computerprogrammprodukt ein Betriebssystem
oder ein Betriebssystemmodul enthalten, das im Zuge der Herstellung oder
der Initialisierung oder der Personalisierung eines tragbaren Datenträgers in
diesen eingebracht wird.
-
Weitere
Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden
Beschreibung eines Ausführungsbeispiels
und mehrerer Ausführungsalternativen
hervor. Es wird auf die Zeichnung verwiesen.
-
1 als einzige Zeichnungsfigur
zeigt ein Blockdiagramm eines Datenträgers nach einem Ausführungsbeispiel
der Erfindung.
-
Der
in 1 dargestellte Datenträger 10 weist
auf einem einzigen Halbleiterchip einen Prozessor 12, einen
Speicher 14 und eine Schnittstellenschaltung 16 zur
kontaktlosen oder kontaktgebundenen Kommunikation mit einem externen
Terminal (nicht gezeigt) auf. Der Speicher 14 ist in mehrere Speicherfelder
unterteilt. Im vorliegenden Ausführungsbeispiel
sind als Speicherfelder ein als RAM ausgestalteter Arbeitsspeicher 18,
ein als ROM ausgestalteter Festwertspeicher 20 und ein
als EEPROM ausgestalteter, nicht-flüchtiger Speicher 22 vorgesehen.
-
Im
Speicher 14 – und
zwar teils im Festwertspeicher 20 und teils im nichtflüchtigen
Speicher 22 – befindet
sich Programmcode, der ein Betriebssystem 24 implementiert.
Das Betriebssystem 24 ist im vorliegenden Ausführungsbeispiel
eine auf den Einsatz im Datenträger 10 zugeschnittene Variante
des unter der Marke Linux bekannten Betriebssystems. Insbesondere
ist das Betriebssystem 24 an die erhebliche Ressourcenbeschränkung des
Datenträgers 10 im Hinblick
auf die Rechenleistung des Prozessors 12 und die Größe des Speichers 14 angepaßt.
-
Der
nicht-flüchtige
Speicher 22 enthält
Datenstrukturen, die einen Dateibaum 26 bilden. Der Dateibaum 26 weist
die für
UNIX-Systeme übliche Struktur
mit einer durch einen Schrägstrich "/" bezeichneten Wurzel und hierarchisch
gegliederten Verzeichnissen und Dateien auf. In 1 sind beispielhaft ein Verzeichnis "etc" für Konfigurationsdateien
und ein Verzeichnis "bin" für diverse
systemnahe Programme gezeigt. Weitere Strukturen des Dateibaums 26 sind
z.B. Querverweise (links) und Gerätedateien (device files), über die
Ein- und Ausgabevorgänge
des Datenträgers 10 durchgeführt werden.
-
In
den Dateibaum 26 sind ein erstes und ein zweites Dateisystem 28, 30 eingebunden.
Das erste Dateisystem 28 ist ein speichersparendes, nicht-transaktionsbasiertes
und nicht-journalführendes
Dateisystem, beispielsweise das an sich bekannte Minix-Dateisystem.
Das zweite Dateisystem 30 ist dagegen als leistungsfähiges, transaktionsbasiertes Dateisystem
ausgestaltet. Im vorliegenden Ausführungsbeispiel ist das zweite
Dateisystem 30 ein journalführendes Dateisystem, z.B. das
unter dem Namen JFS bekannte Dateisystem. In Ausführungsalternativen
ist die Verwendung anderer Dateisysteme vorgesehen. Insbesondere
können
als zweites Dateisystem 30 andere journalführende Dateisysteme
eingesetzt werden, die Aufgaben der Transaktionssicherung vollständig oder
teilweise übernehmen.
-
Das
Einbinden (mounting) der Dateisysteme 28, 30 in
den Dateibaum 26 erfolgt durch einen an sich bekannten
Dienst des Betriebssystems 24. Durch eine unter dem Namen
VFS (virtual filesystem switch) bekannte Softwareschicht des Betriebssystems 24 wird
ferner erreicht, daß auf
die Dateisysteme 28, 30 völlig transparent – also unabhängig von der
unterschiedlichen Technologie der Dateisysteme 28, 30 – zugegriffen
werden kann. Der VFS stellt dazu eine Reihe vordefinierter Zugriffsoperationen bereit,
die einheitlich für
den gesamten Dateibaum 26 anwendbar sind und die in die
tatsächlich
für die Dateisysteme 28, 30 vorhandenen
Zugriffsoperationen umgesetzt werden.
-
In 1 ist beispielhaft ein Anwendungsprogramm 32 gezeigt,
das als Datei im ersten Dateisystem 28 gespeichert ist.
Das Anwendungsprogramm 32 implementiert eine Applikation
des Datenträgers 10,
z.B. eine Applikation als persönliche
Geldbörse. Es
versteht sich, daß weitere
Anwendungsprogramme vorgesehen sein können. Das Anwendungsprogramm 32 setzt
zur Speicherung von Nutzdaten 34, 34' ein auf dem
Gebiet der Chipkarten übliches
Anwendungsprogramm-Dateisystem 36 voraus. Im vorliegenden
Ausführungsbeispiel
ist das Anwendungsprogramm-Dateisystem 36 gemäß der Norm
ISO/IEC 7816-4 mit einem Wurzelverzeichnis MF (master file), weiteren
Verzeichnissen DF (dedicated file) und Dateien EF (elementary file)
für die
Nutzdaten 34, 34' ausgestaltet.
-
Das
Anwendungsprogramm-Dateisystem 36 ist im vorliegenden Ausführungsbeispiel
in dem zweiten, transaktionsbasierten Dateisystem 30 angelegt. Allerdings
spiegelt sich die Verzeichnis- und Dateistruktur des Anwendungsprogramm-Dateisystems 36 nicht
in einer entsprechenden Struktur des zweiten Dateisystems 30 wider.
Vielmehr ist im vorliegenden Ausführungsbeispiel eine einzige
Datei im zweiten Dateisystem 30 vorgesehen, die das gesamte
Anwendungsprogramm-Dateisystem 36 einschließlich aller
Nutzdaten 34, 34' enthält und daher als
Container-Datei 38 bezeichnet wird. Jeder Datei des Anwendungsprogramm-Dateisystems 36 – und in
manchen Ausgestaltungen auch jedem Ordner – entspricht je ein Abschnitt
der Container-Datei 38. Die Container-Datei 38 weist
damit eine interne Struktur auf, die der Struktur des Anwendungsprogramm-Dateisystems 36 entspricht.
-
Ein
Umsetzmodul 40, das in das Betriebssystem 24 integriert
oder an dieses angebunden ist, simuliert das Anwendungsprogramm-Dateisystem 36 auf
für das
Anwendungsprogramm 32 völlig
transparente Weise. Zugriffsoperationen, die das Anwendungsprogramm 32 auf
Grundlage des Anwendungsprogramm-Dateisystems 36 aufruft,
werden vom Umsetzmodul 40 in entsprechende Zugriffe auf
die jeweiligen Abschnitte der Container-Datei 38 umgesetzt, und
die jeweiligen Resultate werden an das Anwendungsprogramm 32 zurückgegeben.
In Ausführungsalternativen
sind statt einer einzigen Container-Datei 38 mehrere Container-Dateien
vorgesehen. Ferner sind auch Ausgestaltungen vorgesehen, bei denen das
Anwendungsprogramm-Dateisystem 36 in eine entsprechende
Struktur im zweiten Dateisystem 30 abgebildet wird.
-
Durch
die Ausgestaltung des zweiten Dateisystems 30 als transaktionsbasiertes,
journalführendes
Dateisystem wird jede Schreiboperation in die Container-Datei 38 zunächst in
einem im nicht-flüchtigen
Speicher 22 angelegten Journal (in 1 nicht gezeigt) vermerkt. Wenn während eines
der beiden Schreibvorgänge
in das Journal bzw. in die Container-Datei 38 eine unerwartete
Betriebsunterbrechung auftritt, kann entweder das Journal oder die Container-Datei 38 eine
inkonsistente Struktur oder einen inkonsistenten Inhalt aufweisen.
Dies wird beim nächsten
Hochfahren des Datenträgers 10 erkannt.
Bei einem beschädigten
Journal werden die darin enthaltenen Einträge verworfen. Bei einer beschädigten Container-Datei 38 wird
die Schreiboperation in die Container-Datei 38 gemäß dem Inhalt des
Journals abgeschlossen. Eine genauere Darstellung dieses Vorgangs
am Beispiel des Ext3-Dateisystems findet sich auf den Seiten 600 – 607 des
eingangs zitierten Buches "Understanding
the Linux Kernel".
-
In
unterschiedlichen Ausgestaltungen umfaßt die vom zweiten Dateisystem 30 bereitgestellte Transaktionssicherung
entweder alle in das zweite Dateisystem 30 einzuschreibenden
Datenblöcke oder
nur Metadaten, die die Struktur des zweiten Dateisystems 30 betreffen.
Wenn nur Metadaten in das Journal aufgenommen werden, kann die Container-Datei 38 nach
einer Betriebsunterbrechung des Datenträgers 10 einen teils
neuen und teils alten Inhalt aufweisen. In diesen Ausgestaltungen
sind daher zusätzliche
Sicherungsmaßnahmen
seitens des Anwendungsprogramms 32 und/oder des Umsetzmoduls 40 erforderlich.
Eine vollständige
Transaktionssicherung wird dagegen in Ausgestaltungen erreicht,
bei denen das Journal den gesamten durch eine Schreiboperation zu ändernden
Dateiinhalt und alle zu ändernden
Metadaten protokolliert.
-
In
dem in 1 gezeigten Ausführungsbeispiel
wird derjenige Teil des Dateibaumes 26, der nicht von den
Dateisystemen 28, 30 eingenommen wird, durch ein
weiteres Dateisystem – z.B.
ein ext2-Dateisystem – gebildet.
-
Es
sind jedoch auch Ausgestaltungen vorgesehen, bei denen die Dateisysteme 28, 30 den
Dateibaum 26 vollständig
aufspannen, so daß kein
weiteres Dateisystem erforderlich ist. Ferner ist in manchen Ausgestaltungen
statt der zwei Dateisysteme 28, 30 für das Anwendungsprogramm 32 und
die Container-Datei 38 ein einziges, transaktionsbasiertes
Dateisystem vorgesehen. Auch in solchen Ausgestaltungen kann der
Dateibaum 26 entweder weitere Dateisysteme aufweisen oder
ausschließlich durch
das transaktionsbasierte Dateisystem gebildet sein.