Diskussion:Inode

Attribute

Im Text steht, dass eine Inode alle Attribute enthält. Aber unter "gespeicherte Informationen" steht dann nichts mehr von den dateiattributen. Werden jetzt die Dateiattribute (bei FAT/NTFS: Schreibgeschützt, Versteckt, System, Archiv) in der Inode gespeichert oder wo anders? -MrBurns 08:34, 15. Mai 2006 (CEST)

Das FAT-Dateisystem besitzt keine Inodes, nur Verzeichniseinträge. Diese enthalten bei FAT sowohl den Dateinamen als auch Metainformationen wie Dateiattribute, Änderungszeiten usw. Inode-basierte Dateisysteme (wie die meisten Unix-Dateisysteme) wiederum besitzen keine Dateiattribute, wie sie FAT besitzt, sondern Bits, die die Zugriffsrechte und den Dateityp (regulär, Verzeichnis, Gerätedatei, Socket, usw.) angeben. Diese sind am ehesten mit den Dateiattributen bei FAT vergleichbar. --RokerHRO 08:07, 16. Mai 2006 (CEST)

Anzahl der Zeiger auf weitere Cluster

Falls die 12 direkten Blockadressen nicht ausreichen, gibt es afaik je einen Zeiger für ein-, zwei- und dreifach indirekt adressierte Blöcke. Also insgesamt 3 Zeiger in der Inode. --84.56.10.253 10:59, 4. Jul 2006 (CEST)

Fehler im Text zum Bild

im Text steht: "Beispiel einer I-Node Struktur mit (16M + 64K + 256) Datenblöcken/Clustern", allerdings wurde bei dieser Berechnung die 10 direkten Blockadressen vergessen. Es sollte also (16M + 64K + 256 + 10) sein.

Fehler im Bild

Wenn ich mich nicht irre, stimmt das Bild nicht ganz.

In der /fs/ext2/inode.c wird die Variable direct_blocks auf den Wert von EXT2_NDIR_BLOCKS gesetzt - dieser wird in /include/linux/ext2_fs.h mit 12 defniert. Also sollte es doch die direkten Blöcke 0 bis 11 statt nur bis 9 geben?

Achso... kurze ergänzung: Nachgeschlagen hab ich das alles direkt im Linuxkernel auf http://lxr.linux.no/linux/fs/ext2/inode.c#L186.

(unsignierter Beitrag offenbar von Thorsten.alge, 23.1.07)

Habe den Text

Diese Abbildung ist nicht ganz Korrekt. Es gibt 12 direkte Blöcke und nicht nur 10. Das war schon bei Unix System Rel. 4 im S5 Filesystem so und die Linux Kernel Quellen stellen das auch so dar.

trotzdem entfernt, weil

• er schlecht dargestellt wurde,
• so etwas auf die Diskussionsseite gehört und
• die offenbar korrekte Anzahl 12 (anstelle der im Bild dargestellten 10) ohnehin im Text steht.

--Tobias 15:16, 27. Mai 2008 (CEST)

In früheren Dateisystem-Versionen (wenn ich mich recht erinnere, bis Sys V.3) waren es 10 direkte Verweise bzw. Blöcke, ab V.4 (seit 1991) dann 12. Das Bild ist also nicht ganz falsch, aber auch nicht mehr ganz aktuell. -- (RK, 4.12.08)

Übersetzung

"Inode (oder I-Node) wird im Deutschen am besten als Informationsknoten oder Indexeintrag bezeichnet."

Das ist doch Nonsense, eine Gewaltübersetzung. Wenn jemand von "Informationsknoten" oder "Indexeintrag" redet, weiss kein Mensch, dass er einen Inode meint. Darum wir auch im Deutschen einfach von "Inode" gesprochen. Ich möchte diesen Satz gerne entfernen. --Oreg 13:50, 27. Jan. 2009 (CET) Erledigt. --Oreg 11:45, 2. Feb. 2009 (CET)

Die Uebersetzung von "Node" als "Knoten" sollte man m.E. schon reinbringen, das ist naemlich der Ursprung und ist auch nicht weit hergeholt, da werden die Dateien, Devices usw. "dran festgemacht". -- 194.8.205.234 00:17, 19. Dez. 2012 (CET)

Maximale Größe von Dateien

Im Beitrag steht, dass die Größe einer Datei von der Blockgröße abhängt. Bei 1KB Blöcken sind Dateien bis 16GB möglich, bei 4KB Blöcken bis 2TB (bei 32 Bit Adressen = 4Byte).

Die 16GB kann ich nachvollziehen (Pro Adressblock gibt es 1024Byte/4Byte = 256 Adressen):

     12   (direkt)
   +256   (1-fach indirekt)
   +256^2 (2-fach indirekt)
   +256^3 (3-fach indirekt)
=  16843020 Datenblöcke; Jeder Block hat 1KB => 16448MB => 16GB

Die 2TB kann ich nicht nachvollziehen (Pro Adressblock gibt es 4096Byte/4Byte = 1024 Adressen):

      12   (direkt)
   +1024   (1-fach indirekt)
   +1024^2 (2-fach indirekt)
   +1024^3 (3-fach indirekt)
= 1074791436 Datenblöcke; Jeder Block hat 4KB => 4*1074791436KB => 4100 GB => 4TB

Ist nun der Artikel fehlerhaft, oder mein Rechenweg? --84.145.112.214 12:22, 29. Mär. 2009 (CEST)

Ich hab da auch Probleme das zu verstehen. Könnte jemand der davon mehr Ahnung hat das ganze verständlicher schreiben ? 178.4.156.218 13:15, 31. Okt. 2016 (CET)

Nicht ausschließlich für Informatiker ...

wird die WP verfasst:

1. imo darf der Einleitungstext durchaus OMA-tauglich sein
   [Für Nicht-Wikipäden: OMA bezeichnet LeserInnen Ohne.Mindeste.Ahnung].
   Wer sich sowieso halbwegs auskennt, wird die Einleitung überfliegen, und wer OMA ist wird die frühere wohl eher als chaotisch empfinden.
2. hat Unix die inodes vielleicht erfunden [?], aber ein 100% unix-orientierter Artikel der sich nicht als ebensolcher deklariert ist nicht gerade "enzyklopädisch".
3. bin ich kein Fachmann, sondern habe den Entwurf anhand des mir unlängst Angelesenen bearbeitet -- sogar MS schrieb verständlicher als die WP ;[ -- die Sichtung überlasse ich gern denen die sich besser auskennen. Gruß, [w.] 11:29, 30. Mär. 2009 (CEST)

Nachtrag: diese Änderung vom 23. 3. sollte bitte ebenfalls jemand checken.

Dazu:

Eine bedauerlicherweise von mir auf einer Privatseite angeregte Diskussion hierzu übertrage ich hiermit hierher, überzeugt, dass die WP nicht ausschließlich für 'Fachleute' verfasst wird.
Das Original liegt dzt. auf Benutzer Diskussion:RokerHRO#Inode
[w.] 18:39, 30. Mär. 2009 (CEST)

Hi, habe mich soeben dort im Entwurf "verwirklicht" und bitte Dich 'reinzulesen, ggf. zu ändern, da mir Dein positiver Diskussionsbeitrag von 2006 auffiel. Hoffe, meine Version der Einleitung ist auch Fachleuten zumutbar (für die sie ja ohnedies nicht gedacht ist). Gruß, [w.] 11:40, 30. Mär. 2009 (CEST)

Wirklich glücklich bin ich mit deinen Änderungen nicht. Es ist viel zu schwammig und blumig geschrieben, ohne dass es dadurch für irgendwen leichter verständlich würde. Was meinst du mit "sehr klein" und "nicht direkt erkennbar"? Beides sind sehr dehnbare Begriffe und sagen nichts konkretes aus. Sowas strengt beim Lesen nur unnötig an, wenn man Fakten sucht aber keine findet. Sie "tragen" auch keine Nummer, sie werden einfach durchnummeriert. Dass NTFS Inodes benutzt, lese ich hier auch zum ersten mal.

"Ein Dateiname verweist als Hardlink auf einen einzigen Inode" ist schlicht falsch.

Die alte Textversion war auch nicht perfekt und teilweise fehlerhaft, darum habe ich deine Änderungen nicht gleich zurückgesetzt. Wenn ich mal mehr Muße habe, versuche ich mal, das ins reine zu bringen.

--RokerHRO 14:31, 30. Mär. 2009 (CEST)

1. "Zu blumig", mag sein. Deswegen habe ich mir ja auch nicht angemaßt, mein Elaborat selber abzusegnen.
2. Für Normalsterbliche ist "erkennbar", was (z.B. in Win) der Explorer oder unter anderen Betriebssystemen ein entsprechendes Tool zeigen.
3. "Sehr klein" sollte die Größenordnung im Verhältnis zum durchschnittlich vermutbaren Inhalt der Datei ausdrücken, also dass es sich quasi um ein "Etikett" handelt. Den Ausdruck "sehr klein" verwendet übrigens weiter unten einer der hier amtierenden Kapazunder, ohne dafür kritisiert zu werden.
4. Reisen bildet, und Lesen auch (NTFS betreffend ;)
5. Ob sie "Nummern tragen" oder unter ebensolchen gefunden/aufgerufen werden können, ist imo eine Frage der Wortwahl, die verbesserungswürdig sein dürfte (siehe [1]), für Genaueres wären LeserInnen gewiss dankbar. Etwa, in welcher Größenordnung/Menge Inodes eingerichtet werden (was ja wohl wiedermal von irgendeinem Zähler abhängt), und exemplarisch erwähnt werden könnte. Wenigstens für das EINE ausführlichst beschriebene Dateisystem, das die Hauptautoren leidlich zu kennen scheinen.

So, genug gemault. Mir wichtige Frage:

• Wie bitte soll EIN Dateiname auf mehr als EINEN Inode verweisen? DIESE Zuordnung ist ja wohl ein-eindeutig, wie Mathematiker zu sagen pflegen (ein Cyber-Bier, wenn ich irre; auf Wunsch auch ein Cyber-Tee, ~Mineralwasser, ~Frufru &c.).

Dass zwischen dem Sprachgebrauch von Technikern und Normalsterblichen mitunter erhebliche Diskrepanzen bestehen, ist mir geläufig, ich wundere mich daher wenig über den imo etwas schnoddrigen Ton der Antwort auf der oben übertragenen Privatseite. [w.] 18:39, 30. Mär. 2009 (CEST)

Mir war die Einleitung vorher auch zu unklar. Allerdings klingt sie mir jetzt zu sehr nach der Sendung mit der Maus, ohne dadurch wirklich klarer geworden zu sein. Metaphern wie "Türschild" sind meiner Ansicht nach kein enzyklopädischer Stil. Inodes sind so speziell, dass sich ohnehin nur Leute mit einem gewissen Hintergrund für den Artikel interessieren werden. Kurz: Ich teile W.s Kritik, bin aber mit der angebotenen Lösung noch nicht glücklich. --Oreg 00:24, 31. Mär. 2009 (CEST)

Betr. "Sendung mit der Maus"-Stil hast Du schon Recht, das "Türschild" streiche ich wohl demnächst. Betr. "nicht klarer" glaub' ich Dir nicht, und betreffend "interessiert nur Fachleute" liegst Du ziemlich sicher falsch: Wer den Begriff in der WP sucht, ist imo von Fachwissen "unbelastet", oder wenigstens, darf es sein. Und:

Die Einleitung muss nicht ins Spezielle gehen, das tut der Artikel (soweit ich's beurteilen kann). Ich glaube übrigens inzwischen, dass eine simple Grafik das Thema für Laien (wie mich ;) veranschaulichen würde. Diese könnte dann auch für das Lemma hard link genutzt werden. [w.] 08:21, 31. Mär. 2009 (CEST)

Unter Windows&c

Zum heute im Entwurf "geborenen" vorläufigen Satz

Unter Windows verhält sich das Dateisystem NTFS ähnlich.

b.i.t.t.e ich um Kommentare durch jemanden, dem NTFS wenigstens annähernd bekannt ist:

[Meine] Primärfrage ist die Wortwahl "ähnlich" vs. "analog", aber DAVOR steht immer noch, ob's nicht möglich wäre [ES W.Ä.R.E!!!], den dzt. voll UNIX/ext2-bezogenen Artikel a.l.l.g.e.m.e.i.n zu halten: so etwa nutzt auch MacOS-X [wie auch immer man das schRei.i.i.bpt] in-etwa sowas. [w.] 18:39, 30. Mär. 2009 (CEST)

Laut diesem Artikel [1] sind die File Records bei NTFS nicht das gleiche wie Unix Inodes. --Oreg 00:24, 31. Mär. 2009 (CEST)

Danke für diesen Link, der mich betreffend möglicher OMA-Tauglichkeit einer allgemein gehaltenen Einleitung, oder sogar eines systemübergreifend formulierten Artikels, total ernüchtert hat: Bei der Suche nach Erklärung für hard links unter WinXP/NTFS war ich auf Erklärungen für die Linux-Ebene geraten, ohne dass mir der grundlegende Unterschied auffiel. Dazu kam's nicht zuletzt durch den ohnedies mehrfach kritisierte Artikel Harter Link, dessen Einleitung ausschließlich auf Inode verweist, ohne Windows zu erwähnen. Ich versuche noch eine entsprechende Nachbesserung meines gestrigen Edits, bevor ich wohl das Handtuch werfe um bei meinen Leisten weiter zu machen. [w.] 09:13, 31. Mär. 2009 (CEST)

Mein letzter Edit

In der begründeten Hoffnung, die Artikelversion vom 23. unter Berücksichtigung von Oregs Einwänden jetzt eindeutig verbessert zu haben, habe ich die letzte Version als "gesichtet" markiert.
Gestrichen wurde insbesondere:

• ..."ähnlich einem Primärschlüssel in einer Datenbank" aus der Einleitung. Dort erzeugt das bloß Verwirrung, dass es in die genauere Beschreibung hineinsoll bezweifle ich ebenfalls.
• Die Anleitung zum Erstellen von Hardlinks -- war hier off-topic
• Die Erklärung für (...Hardlinks = Namen der Datei, das heißt Zahl der Verweise aus den Verzeichnissen auf die Datei, unter "Referenzzähler".

Mögliche Fehler, die irrtümlich entstanden/verblieben sein könnten:

• Alle Zahlenangaben wurden ungesichtet übernommen
• Inode ist ein Eintrag in einem Unix-Dateisystem OK??
• aufgrund meines Verständnisses des Artikels Unix-Dateirechte schiene es weit übersichtlicher, die ersten drei Listenpunkte für den Inhalt des Inodes zu einem einzigen zusammenzufassen:
• Zugriffsrechte (für Eigentümer, Gruppen und Sonstige). -- allerdings war ich dafür nicht mutig genug.
• "bis zu 12 Verweise..." ersetzt jetzt die Schwurbelkonstruktion mit "beziehungsweise" -- aber: stimmt das allgemein, oder bloß für ext2?

Fragen:

• Die Formulierungen "In den meisten Unix-Betriebssystemen werden Dateien nur über ihre Inodes aufgerufen." und
  "...Inhalt wird von den meisten heutigen Dateisystem-Implementierungen..." sind zu schwammig -- hier wäre wenigstens je eine Ausnahme zu nennen (ich nehme nehme an, es handelt sich um veraltete oder kleingestutzte Distributionen, die ohne Inodes auskommen?).
• Da sich lt. Artikel (weit unten) eine Liste aller nicht belegten Inodes erstellen lässt, scheint die maximale Anzahl möglicher Inodes fix vorgegeben -- falls ja, wäre ein Beispiel für diese Größe wünschenswert. Falls ich das falsch verstehe, wäre eine Erklärung angebracht, wie Inodes gebildet werden (entstehen) und wie es zu "nicht belegten" Inodes kommt.
• Die enWP bezeichnet Inodes als Datenstruktur, was ich aber nicht übernommen habe, da die deWP Datenstrukturen als "nicht nur durch ihre beinhalteten Daten charakterisiert" bezeichnet, was gem. dem Artikel Inode aber nicht zuzutreffen scheint, oder?

Gruß, [w.] 11:42, 31. Mär. 2009 (CEST)

Nachtrag: Am Artikel Harter Link habe ich mich abschließend auch noch versucht -- vermutend, dass ich ihn nicht verschlechtern könne ;] -- falls jemand dort drüberliest, wird die Menschheit es uns danken, oder auch nicht ... [w.] 13:36, 1. Apr. 2009 (CEST)

Wo wird denn nun der Dateiname gespeichert?

Der dateiname verweist auf ein inode. Und wo wird der dateiname gespeichert? Neoexpert 13:26, 1. Feb. 2011 (CET)

Die Frage ist zwar schon etwas älter, ich habe die Beantwortung trotzdem mal dem Artikel hinzugefügt (Nach der Auflistung was ein Inode enthält). Milania (Diskussion) 20:45, 10. Sep. 2012 (CEST)

FAT

Es fehlt jegliche Aussage zu Inodes und FAT-Dateisystemen. --Itu 09:27, 16. Sep. 2011 (CEST)

Ich verstehe nicht ganz: Ist es nicht so, dass es bei FAT gar keine Inodes gibt? Warum sollte man das extra erwähnen? In den Amiga-Dateisystemen gibt es auch keine Inodes, sollen die dann auch noch hier rein? --PeterFrankfurt 01:36, 17. Sep. 2011 (CEST)

Ich weiss jetzt nicht genau ob es bei FAT keine inodes gibt. Ich weiss aber dass ich bei meinem gemounteten USB-laufwerk mit FAT mit ls -i genauso inodes angezeigt bekomme wie bei ext. --Itu 23:56, 17. Sep. 2011 (CEST)

Im Artikel File Allocation Table finde ich jedenfalls keine Erwähnung von Inodes. --PeterFrankfurt 01:14, 18. Sep. 2011 (CEST)

Verzeichnisse und andere Knotentypen unter *ix

Was m.E. evtl. noch von Interesse waere (falls es nicht zu speziell ist, WP soll ja kein Lehrbuch sein) :

- Verzeichnisse sind auf vielen *ix-Filesystems nichts weiter als strukturierte Dateien und benoetigen daher (mindestens) eine Inode, waehrend sie z.B. auf FAT in einem separaten (relativ) geschuetzten Speicherbereich ausserhalb des eigentlichen Datenbereiches verwaltet werden.

- Verzeichnisse haben immer mindestens 2 Inodes, naemlich eine, die auf sie selbst verweist (".") und eine zum uebergeordneten Verzeichnis (".."). Der Inode-Zaehler wird beim "ls -l" auch vorn angezeigt, so dass man Dateien mit Hardlinks identifizieren kann. Ausnahme ist meines Wissens nur Root, bei dem beide Links auf die gleiche Verzeichnisdatei verweisen.

- Loescht man eine Inode (unlink), dann existiert die Datei weiter, ist aber nicht mehr zugreifbar. Loescht man die Inode eines Verzeichnisses zum uebergeordneten Verzeichnis, dann kann man sich unterhalb des Verzeichnisses so lange weiter bewegen, bis man einmal raus ist, dann kommt man nie wieder rein. Sviw. findet nur fsck solche Inkonsistenzen und ist in der Lage, sie zu bereinigen.

- Inodes (spezielle, z.B. Devices und Named Pipes, aber auch regulaere) koennen auf relativ niedriger Ebene mit mknod erzeugt werden. Leider sind alle 3 Erwaehnungen des mknod-Kommandos in der deutschen WP diesbezueglich fehlerhaft oder unvollstaendig, hier waere m.E. ein guter Ort, das mal zurechtzuruecken.

- Die maximale Anzahl der Knoten je log. Platte ist (zumindest bei aelteren Systemen) bei der Kernelgenerierung einzustellen, die Inode-Belegung wird neben dem Plattenplatz auch beim Kommando "df" angezeigt. Ist das Limit erreicht, kann man keine weiteren Dateien anlegen, auch wenn noch viel Platz auf der Partition ist.

Ich kenne nur aeltere Filesystems und bin auch kein "Systemer", daher bringe ich mein 2/3-Wissen erstmal nur hier ein -- 194.8.205.234 00:49, 19. Dez. 2012 (CET)

Satzbau

Werter Michael »Michi« Schönitzer,

stilistisch anstößig ist im Abschnitt »Verzeichnisse« die Bearbeitung des Satzes

»Für jedes Verzeichnis existieren immer die Einträge „.“ für das aktuelle und „..“ für das übergeordnete Verzeichnis.« (2. April 2014 09:57, Grixlkraxl)

Zugrunde liegt der missglückten Neufassung

»Für jedes Verzeichnis existieren immer die Einträge . als Verweise auf das aktuelle und .. für das übergeordnete Verzeichnis.« (16. Juni 2015 18:11, MichaelSchoenitzer)

die (inhaltlich wie formal) parallel gebaute Parataxe

»der Eintrag a als Verweis auf x und der Eintrag b als Verweis auf y«.

Beide Satzteile können aufgrund gemeinsamer Satzteilglieder zusammengezogen werden zu:

»die Einträge a und b als Verweise auf x bzw. y«.

Die Konjunktion beziehungsweise bedeutet in dieser Konstruktion so viel wie und im anderen Fall[e]. Beispiel: »Der Träger des Gelben Trikots darf sich in Paris über 450.000 Euro freuen. Für die Plätze zwei und drei werden noch 200.000 bzw. 100.000 Euro ausgeschüttet.« (Quelle: SID)

Für den überarbeiteten Satz ergibt sich mithin:

»Für jedes Verzeichnis existieren immer die Einträge . und .. als Verweise auf das aktuelle bzw. übergeordnete Verzeichnis.«

MfG Thorsten, Hamburg – PunPunKomStr 10:34, 17. Sep. 2015 (CEST)

Bedeutung von "stat" und "find" für das Arbeiten mit Inodes

Im Abschnitt Praxis würde ich gerne die Bedeutung der Befehle stat und find für das Arbeiten mit Inodes hervorheben und folgendes Beispiel einbauen:

# Wir legen die Datei /tmp/meine_testdatei.txt an. 
echo "Ich liebe Wikipedia." > /tmp/testdatei.txt

# Wir ermitteln den Inode der neuen Datei indem wir die Ausgabe 
# des Befehls stat in der Variablen 'my_inode' speichern
my_inode=$( stat --printf="%i" /tmp/testdatei.txt )

# Wir geben den ermittelten Wert der Inode aus. 
echo "Für /tmp/testdatei.txt wurde der Inode ${my_inode} ermittelt."

# Wir legen den Hardlink /tmp/hardlink_auf_testdatei.txt an
ln /tmp/testdatei.txt /tmp/hardlink_auf_testdatei.txt

# wir listen alle Dateien mit dem oben ermittelten Inode.
# Mögliche Fehlermeldungen wie "Permission denied" werden 
# nach /dev/null umgeleitet.
echo "Gefundene Dateien mit Inode ${my_inode}:"
find /tmp -xdev -inum ${my_inode} -print 2>/dev/null

# Wir löschen die ursprüngliche Datei. 
# Der Inhalt bleibt im Hardlink erhalten! 
rm /tmp/testdatei.txt

# Wir listen nochmal alle Dateien mit dem Inode my_inode. 
# Diesmal verwneden wir den Befehl ls und Filtern mit grep.
# Es existiert nur noch eine Datei mit dem Inode! 
echo "Nochmal eine Liste aller gefundenen Dateien mit Inode ${my_inode}"
echo "(inzwischen wurde /tmp/testdatei.txt gelöscht):"
ls -i /tmp | grep "^ *${my_inode} "

# Wir geben den Inhalt von /tmp/hardlink_auf_testdatei.txt aus 
# und sehen das er identisch mit dem der gelöschten Datei ist. 
echo "Inhalt von /tmp/hardlink_auf_testdatei.txt:"
cat /tmp/hardlink_auf_testdatei.txt

# Wir räumen auf und löschen auch /tmp/hardlink_auf_testdatei.txt.
rm /tmp/hardlink_auf_testdatei.txt

--TapTun (Diskussion) 16:33, 7. Mai 2023 (CEST)