Warum sollten Sie selbst und übergeordnete Links (. Und ..) in einem Verzeichniseintrag speichern?

11

Stellen Sie sich ein Dateisystem vor, das auf einige eingebettete Geräte ausgerichtet ist und nur Dateien in einer hierarchischen Verzeichnisstruktur speichert. In diesem Dateisystem fehlen viele der Vorgänge, die Sie möglicherweise in Systemen wie Unix und Windows gewohnt sind (z. B. sind die Zugriffsberechtigungen völlig unterschiedlich und nicht an in Verzeichnissen gespeicherte Metadaten gebunden). Dieses Dateisystem erlaubt keine Art von Hardlink oder Softlink, daher hat jede Datei einen eindeutigen Namen in einer strengen Baumstruktur.

Hat das Speichern eines Links zum Verzeichnis selbst und zu seinem übergeordneten Element in der Datenstruktur auf der Festplatte, die ein Verzeichnis darstellt, einen Vorteil?

Die meisten Unix-Dateisysteme haben .und ..Einträge auf der Festplatte. Ich frage mich, warum sie diese auf der VFS-Ebene (Generic Filesystem Driver) nicht verarbeiten. Ist das ein historisches Artefakt? Gibt es einen guten Grund und wenn ja, welchen genau, damit ich feststellen kann, ob er für mein eingebettetes System relevant ist?

operating-systems filesystems

— Gilles 'SO - hör auf böse zu sein'
quelle

Ich habe immer gedacht, dass sie nur virtuell da sind, damit Programme problemlos auf das aktuelle und übergeordnete Verzeichnis zugreifen können. Interessante Frage, aber gehört sie hierher?

— Raphael

@Raphael Ich könnte verstehen, wenn Sie meine Frage als zu weit gefasst (→ „keine echte Frage“) oder vielleicht als „nicht konstruktiv“ betrachten, weil sie etwas offen ist. Aber ich bin nicht der Meinung, dass es kein Thema ist: Es geht um Dateisystemdesign, wie ist das nicht angewandte Informatik? Wenn Sie der Meinung sind, dass dies kein Thema ist, erläutern Sie bitte Ihre Argumentation zu Meta.

— Gilles 'SO - hör auf böse zu sein'

@ Raphael Ich habe meine Frage bearbeitet, hoffentlich sollte klar sein, dass mein Standpunkt der eines Embedded OS-Designers ist. Danke für deine Kommentare.

— Gilles 'SO - hör auf böse zu sein'

2

Links zum übergeordneten Verzeichnis zu haben, macht für mich Sinn. Wenn Sie sie nicht hätten, müssten Sie immer mit einer ganzen Liste von Verzeichnissen arbeiten. So /home/svick/Documents/müsste zum Beispiel dargestellt werden als { /, /home/, /home/svick/, /home/svick/Documents }. Wenn Sie das nicht tun würden, könnten Sie das übergeordnete Verzeichnis überhaupt nicht finden (oder es wäre sehr teuer). Dies ist nicht nur ineffizient, sondern auch gefährlich. Wenn Sie zwei solcher Listen haben, die sich überschneiden, können sie leicht desynchronisiert werden, wenn Sie ein Verzeichnis verschieben.

Wenn Sie jedoch einen Verweis auf das übergeordnete Verzeichnis haben, ist dies effizienter und sicherer.

Ich sehe keinen Grund, tatsächlich einen Link zum aktuellen Verzeichnis zu haben. Wenn Sie eine Struktur haben, die ein Verzeichnis darstellt, und auf dieses Verzeichnis zugreifen möchten, ist die Verwendung .immer völlig unnötig. Aus diesem Grund würde ich erwarten, dass der .Link in der Dateisystemstruktur nicht vorhanden und nur virtuell ist.

— svick
quelle

2

Gleiche Bemerkung: Warum in jedem Dateisystem und nicht in der VFS-Schicht? Die meisten Linux-Dateisysteme haben .und ..Einträge.

— Gilles 'SO - hör auf böse zu sein'

Wie gesagt, ich denke es ist effizienter. Sie können nur mit dem aktuellen Verzeichnis arbeiten und nur dann auf die übergeordneten Verzeichnisse zugreifen, wenn Sie dies benötigen. Wenn Sie keine übergeordneten Links hätten, müssten Sie immer alle Verzeichnisse im gesamten Pfad von root im Speicher behalten. Und das würden Sie für jeden Eintrag benötigen, den Sie verwenden.

— Svick

1

@svick: Gilles vergleicht nicht mit übergeordneten Links mit nicht übergeordneten Links. Er vergleicht sie im tatsächlichen Dateisystem mit der Simulation durch eine Zwischencodeschicht (vfs) zwischen dem tatsächlichen Dateisystem und dem Benutzerbereich.

— Rgrig

2

Sie erhalten weniger Sonderfälle. In vielen Situationen kann VFS ".." wie jeden anderen Verzeichnisnamen behandeln.

— rgrig
quelle

3

Wenn die Verzeichnisse virtuell sind, kann das Programm (ich nehme an, der Benutzermodus) es weiterhin wie jedes andere Verzeichnis behandeln. Sie benötigen die Links nicht wirklich, um sie auf Speicherebene zu präsentieren.

— Aryabhata

1

Ja, aber warum nicht auf der VFS-Ebene damit umgehen? Warum sollte es einen zugehörigen Speicher geben?

— Gilles 'SO - hör auf böse zu sein'

Warum implementieren Benutzer verknüpfte Listen mit einem Sentinel, anstatt sich um den leeren Listenfall in den Funktionen zum Hinzufügen / Entfernen zu kümmern?

— Rgrig

@rgrig: Dies geschieht nur, wenn die Schnittstelle zur betrachteten verknüpften Listenimplementierung in einer Sprache geschrieben ist, die im Umgang mit induktiven Datenstrukturen (C, Java usw.) außergewöhnlich schlecht ist. Hier ist dieses Problem nicht relevant, da die VFS-Schicht aus Benutzersicht nicht direkt zugänglich ist.

— Stéphane Gimenez

@ StéphaneGimenez: Dieses Problem ist relevant, weil VFS ist in C geschrieben

— rgrig

2

Der einzige Grund, den ich mir vorstellen kann, ist das folgende Szenario:

Eine ursprüngliche Implementierung eines Dateisystems existierte mit demselben Verzeichnisformat, aber die Begriffe Dateipfade und Unterverzeichnisse wurden zu diesem Zeitpunkt nicht berücksichtigt (siehe Das PDP-7-Unix-Dateisystem ).
Dann dachten die Leute, dass Pfadauflösung und Unterverzeichnisse nützlich wären!
Um ein gewisses Maß an Abwärtskompatibilität mit älteren Implementierungen zu gewährleisten, wurde beschlossen, dass das .und ..wie jedes andere Verzeichnis auf der Festplatte gespeichert wird.

Vielleicht bleiben uns diese nutzlosen Artefakte, nur um die Abwärtskompatibilität mit 40 Jahre alter Software zu gewährleisten? Glaubwürdiges Szenario?

Hinweis: Es war auch nicht ganz dumm, diese Einträge zur Verzeichnisliste hinzuzufügen, da Sie die Inode-Nummer Ihres echten übergeordneten Verzeichnisses ohnehin irgendwo speichern müssen (denken Sie daran, dass zu diesem Zeitpunkt Hardlinks zu Verzeichnissen zulässig waren) und einen Verweis auf Ihre Eine eigene Inode-Nummer könnte eine gute Überprüfung der Gesundheit sein.

— Stéphane Gimenez
quelle

1

Ich sehe keinen Grund , zu implementieren .und ..zu beiden Ebenen eher als die andere. Wenn Sie jedoch auf eingebettete Systeme abzielen, kann jede Ebene, die Sie sparen können, Geld verdienen. Daher ist es möglicherweise sinnvoll, alles so niedrig wie möglich zu implementieren.

Wie für die allgemeine Notwendigkeit von . und ..betrifft, wie würden Sie relative Pfade ohne sie ausdrücken? Zumindest ..für Pfade, die den aktuellen Teilbaum verlassen, unverzichtbar. Wenn Sie solche Pfade nicht benötigen (möglicherweise ist der Baum eine primitive Methode zum Codieren von Zugriffsberechtigungen?), Benötigen Sie diese nicht ...

— Raphael
quelle