Hard Links

S

Serow

0
Hi,

ich war bisher immer der Meinung, dass Hard Links, auch wenn sie auf die gleichen Datenblöcker zeigen, unterschiedliche Inode Numbers haben. Das ist offensichtlich nicht so:

Code: 
mathias@wizard:/tmp/test$ echo "my file" > file1
mathias@wizard:/tmp/test$ ln file1 file2
mathias@wizard:/tmp/test$ ls -l
total 8
-rw-r--r-- 2 mathias mathias 8 2009-04-18 16:38 file1
-rw-r--r-- 2 mathias mathias 8 2009-04-18 16:38 file2
mathias@wizard:/tmp/test$ cat file2 
my file
mathias@wizard:/tmp/test$ cat file1
my file
mathias@wizard:/tmp/test$ stat file1
  File: `file1'
  Size: 8               Blocks: 8          IO Block: 4096   regular file
Device: 807h/2055d      Inode: 23000       Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/ mathias)   Gid: ( 1000/ mathias)
Access: 2009-04-18 16:38:34.000000000 +0200
Modify: 2009-04-18 16:38:23.000000000 +0200
Change: 2009-04-18 16:38:27.000000000 +0200
mathias@wizard:/tmp/test$ stat file2
  File: `file2'
  Size: 8               Blocks: 8          IO Block: 4096   regular file
Device: 807h/2055d      Inode: 23000       Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/ mathias)   Gid: ( 1000/ mathias)
Access: 2009-04-18 16:38:34.000000000 +0200
Modify: 2009-04-18 16:38:23.000000000 +0200
Change: 2009-04-18 16:38:27.000000000 +0200
mathias@wizard:/tmp/test$

Und scheinbar sind auch die timestamps der Inodes zwingend gleich?
Code: 
mathias@wizard:/tmp/test$ stat file1
  File: `file1'
  Size: 8               Blocks: 8          IO Block: 4096   regular file
Device: 807h/2055d      Inode: 23000       Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/ mathias)   Gid: ( 1000/ mathias)
Access: 2009-04-18 16:41:16.000000000 +0200
Modify: 2009-04-18 16:41:16.000000000 +0200
Change: 2009-04-18 16:41:16.000000000 +0200
mathias@wizard:/tmp/test$ stat file2
  File: `file2'
  Size: 8               Blocks: 8          IO Block: 4096   regular file
Device: 807h/2055d      Inode: 23000       Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/ mathias)   Gid: ( 1000/ mathias)
Access: 2009-04-18 16:41:16.000000000 +0200
Modify: 2009-04-18 16:41:16.000000000 +0200
Change: 2009-04-18 16:41:16.000000000 +0200
mathias@wizard:/tmp/test$ date
Sat Apr 18 16:42:02 CEST 2009
mathias@wizard:/tmp/test$ touch file2
mathias@wizard:/tmp/test$ stat file1
  File: `file1'
  Size: 8         	Blocks: 8          IO Block: 4096   regular file
Device: 807h/2055d	Inode: 23000       Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/ mathias)   Gid: ( 1000/ mathias)
Access: 2009-04-18 16:42:05.000000000 +0200
Modify: 2009-04-18 16:42:05.000000000 +0200
Change: 2009-04-18 16:42:05.000000000 +0200
mathias@wizard:/tmp/test$ stat file2
  File: `file2'
  Size: 8               Blocks: 8          IO Block: 4096   regular file
Device: 807h/2055d      Inode: 23000       Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/ mathias)   Gid: ( 1000/ mathias)
Access: 2009-04-18 16:42:05.000000000 +0200
Modify: 2009-04-18 16:42:05.000000000 +0200
Change: 2009-04-18 16:42:05.000000000 +0200

Also sehe ich das richtig, dass Hard Links keine eigenen Inodes sind sondern Inodes nur "pro File / Directory" existieren und ein Hard Links quasi eher als der Eintrag des Files im Directory zu sehen ist?

Code: 
mathias@wizard:/tmp/test$ ls -i
23000 file1  23000 file2
mathias@wizard:/tmp/test$

Falls ich es jetzt endlich verstanden haben sollte, bitte kurz bestätigen :D

cu
serow
 
Hm, ein Inode ist doch nur eine Datenstruktur die Metadaten über eine Datei enthält (Größe, letzter Zugriff, usw).

Und afaik sind die Inodes nicht direkt mit den Dateien/Ordnern verknüpft sondern die Zuordnung geschieht über Inode-Nummern in sogenannten Inode-Tables.

Zu den HardLinks hab ich auf die Schnelle noch das gefunden:
This detaching of a file's name from its other metadata is what allows the system to implement hard links and thus have multiple names for any file. A hard link is an entry in a directory that contains a pointer directly to the inode bearing the file's metadata. When a new hard link to a file is created, both links share the same inode number because the link is only a pointer, not a copy of the file.
Zum Vergrößern anklicken....

http://www.linfo.org/inode.html
 
Wenn du nun 2 identische Dateien anlegst, wäre es möglich, dass dein FS dafür nur 1 Inode brauch, da die Metadaten gleich sind... aber das ist ehrlich gesagt nur eine Vermutung. So gut kenne ich mich da auch nicht aus.
Zum Vergrößern anklicken....
Halt ich für falsch. Nach meinem Verständnis würde das einen Mechanismus wie Transparent Page Sharing oder File System Deduplication vorraussetzen.

Ich hab mir bisher diese Inode-Table ähnlich einer Datenbanktabelle vorgestellt und die Inode Number als den Primary Key der Tabelle gesehen sozusagen. Die Tatsache, dass zwei Hard Links die gleiche Inode Number haben, wirft diese Vorstellung irgendwie über den Haufen ;)

cu
serow
 
Ich hab den Absatz gestrichen als ich mir selbst mal den Artikel durchgelesen habe, aus dem das Zitat stammt. :D

Dort steht zumindest erklärt wieso die Hardlinks dieselben Inode-Nummern haben: Es sind in dem Sinne keine Dateien oder Kopien der Dateien o.ä., sondern einfach nur Pointer, die auf den Inode der verlinkten Datei zeigen. Daher haben die Hardlinks dieselben Inode-Nummern.

Wie nun die Inode-Table genau aufgebaut ist bzw funktioniert, kann ich dir leider auch nicht sagen. Aber mittels Google dürftest du da ja noch genug Material finden um damit den Abend zu füllen. :P
 
Wie nun die Inode-Table genau aufgebaut ist bzw funktioniert, kann ich dir leider auch nicht sagen. Aber mittels Google dürftest du da ja noch genug Material finden um damit den Abend zu füllen.
Zum Vergrößern anklicken....
Genau das wollte ich vermeiden :P

Also zusammenfassend:
  1. 1 Inode pro File / Directory
  2. und damit auch 1 Inode Number pro File / Directory
  3. ein hard link ist nich gleichzusetzen mit einer Inode
  4. sondern mit einem Eintrag einer Inode in ein Directory File
    [/list=1]

    Wenn mir das jetzt niemand um die Ohren haut hab ich's wohl endlich WIRKLICH gecheckt ^^

    cu
    serow
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben