Hallo Liste, mir ist da was mit Hardlinks nicht ganz klar. Ich dachte mir bisher, daß ein Hardlink auf eine Datei vom "Original-Hardlink" nicht zu unterscheiden ist. Ich habe gegoogelt, und las, daß bereits der erste Dateiname nur ein Hardlink auf die Datei sei, und ebenso würde es sich mit den weiteren Dateinamen verhalten. Dem scheint aber nicht so zu sein: Ich habe # ls -1 dir1 dir2 dir3 In dir1 liegt eine Datei mit 100 MB: # ll dir1 -rw------- 1 andre users 105822208 2006-08-08 14:25 datei Die kopiere ich nun mittels rsync nach dir2: # rsync -a dir1/ dir2/ # ll dir2 -rw------- 2 andre users 105822208 2006-08-08 14:25 datei Nun kopiere ich diese Datei per rsync in dir3: # rsync -a \ --link-dest=~/test/dir2/ ~/test/dir1/ ~/test/dir3/ # ll dir3 -rw------- 2 andre users 105822208 2006-08-08 14:25 datei # stat dir3/datei File: „dir3/datei“ Size: 105822208 Blocks: 206696 IO Block: 4096 reguläre Datei Device: 700h/1792d Inode: 80644803 Links: 2 Die Zahl der Links ist 2, d.h. die Datei in dir3 ist nur ein Hardlink auf die Datei in dir2. rsync hat also nur gelinkt, statt kopiert. Warum ergibt jetzt: # du -hs * 101M dir1 101M dir2 0 dir3 Wieso wird nicht auch für dir3 101 MB als Größe ausgegeben? Wie wird unterschieden zwischen dem ersten Dateinamen und allen weiteren Dateinamen? Danke für eure Erhellung. -- Andre Tann
Warum ergibt jetzt: # du -hs * 101M dir1 101M dir2 0 dir3
Wieso wird nicht auch für dir3 101 MB als Größe ausgegeben? Wie wird unterschieden zwischen dem ersten Dateinamen und allen weiteren Dateinamen?
man du: -l, --count-links count sizes many times if hard linked du zeigt dir standardmäßig nur die tatsächliche Größe an, die auch wirklich belegt wird.
Dominik Klein wrote:
Warum ergibt jetzt: # du -hs * 101M dir1 101M dir2 0 dir3
Wieso wird nicht auch für dir3 101 MB als Größe ausgegeben? Wie wird unterschieden zwischen dem ersten Dateinamen und allen weiteren Dateinamen?
man du: -l, --count-links count sizes many times if hard linked
du zeigt dir standardmäßig nur die tatsächliche Größe an, die auch wirklich belegt wird.
Hallo Dominik, wenn ich Dich richtig verstehe, weißt Du nicht wirklich was ein Hardlink ist! Sehe ich das richtig? Unter MS(WIN)DOOF enthalten Verzeichnisse die kompletten Daten zu Dateinamen, Zeitstempel etc. Ich weiß zwar nicht exakt, wie es unter Linux/Unix gelöst ist, ich weiß aber, daß es dort nicht so ist. Das "Verzeichnis" ist unter Linux mehr oder weniger auch "nur" eine Datei, die lediglich (hauptsächlich) die Namen der Datei (bzw. des Eintrags) und dann nur noch einen Link, die sogenannte inode Nummer, auf die eigentlichen Daten enthält. Deshalb ist auch der einzige Eintrag einer Datei eigentlich nur ein "Hardlink". Dies funktioniert aber nur innerhalb ein und desselben Dateisystems. Dateisystemübergreifend ist dies nicht möglich, weshalb es die sogenannten Symlinks gibt, welche dann einfach einen Texteintrag als Adresse auf den "eigentlichen" Dateieintrag enthalten. Ich hoffe, damit ist Dir (ausreichend) geholfen. Gruß Martin
man du: -l, --count-links count sizes many times if hard linked
du zeigt dir standardmäßig nur die tatsächliche Größe an, die auch wirklich belegt wird. Hallo Dominik,
wenn ich Dich richtig verstehe, weißt Du nicht wirklich was ein Hardlink ist! Sehe ich das richtig?
Wie du anhand meines Postings zu dieser Annahme kommst erschließt sich mir leider nicht. Ich denke ich weis sehr wohl, was ein Hardlink ist. Aber das tut eigentlich auch nichts zur Sache. Back to topic: "du" zählt ein inode eben standardmäßig nur einmal. Wenn es einen Hardlink findet, der auf ein bereits gelesenes inode zeigt, wird es nicht in die Größenberechnung einbezogen. Will man hingegen, dass doch "alles" gezählt wird, kann eben "-l" angegeben werden. Damit ist doch die ganze Hexerei eigentlich geklärt oder?
Dominik Klein, Dienstag, 8. August 2006 15:24:
du zeigt dir standardmäßig nur die tatsächliche Größe an, die auch wirklich belegt wird.
Welche Größe wird denn "wirklich" belegt? Die Datei, zu der der Eintrag in dir3 gehört, belegt doch 100 MB...? Irgendwo las ich, daß ein Hardlink nichts weiter ist als ein weiterer Henkel am Topf (=der Datei). Sobald sämtliche Henkel (=Hardlinks) gelöscht wurden, wird der Topf gelöscht, sprich: der Platz wieder freigegeben. Worin unterscheidet sich der erste von allen weiteren Henkeln? -- Andre Tann
Andre Tann, Dienstag, 8. August 2006 16:27:
Welche Größe wird denn "wirklich" belegt? Die Datei, zu der der Eintrag in dir3 gehört, belegt doch 100 MB...?
Und noch weiter gefragt: angenommen, ich lösche den Eintrag in dir2, also den ersten Henkel am Topf, dann existiert die Datei ja immer noch, allerdings ist jetzt der Henkel in dir3 der einzige. Wie groß ist jetzt die Datei in dir3? Lt. "du" sind es jetzt 100 MB. Aber die Größe einer Datei kann ja nicht davon abhängen, ob ich in einem anderen Verzeichnis etwas lösche...? Und welcher Art sind die Henkel jetzt? Hat die Datei nur noch einen Zweithenkel? Naja, irgendwie denke ich vielleicht zu kompliziert, aber so recht klar ist mir das noch nicht. -- Andre Tann
On Tuesday 08 August 2006 16:27, Andre Tann wrote:
Dominik Klein, Dienstag, 8. August 2006 15:24:
du zeigt dir standardmäßig nur die tatsächliche Größe an, die auch wirklich belegt wird.
Welche Größe wird denn "wirklich" belegt? Die Datei, zu der der Eintrag in dir3 gehört, belegt doch 100 MB...?
Irgendwo las ich, daß ein Hardlink nichts weiter ist als ein weiterer Henkel am Topf (=der Datei). Sobald sämtliche Henkel (=Hardlinks) gelöscht wurden, wird der Topf gelöscht, sprich: der Platz wieder freigegeben.
Worin unterscheidet sich der erste von allen weiteren Henkeln?
Überhaupt nicht. Sie sind ledig andere Namen für das gleiche File. Malcolm
-- Andre Tann
Hallo, Am Die, 08 Aug 2006, Andre Tann schrieb:
Worin unterscheidet sich der erste von allen weiteren Henkeln?
Gar nicht. Eine Datei ist: - Ein Verzeichniseintrag mit der Zuordnung: Name => Inode-Nummer - Der Inode mit allen Metadaten _außer_ dem Namen sowie die eigentlichen Daten Ein 'ln foo bar' ist nur eine Methode einem Inode einen weiteren Namen zu geben. Es wird dabei ausschließlich der Verzeichniseintrag erstellt und der Link-Count im Inode um eins erhöht. Bei einem 'rm' wird intern "nur" ein 'unlink(2)' aufgerufen. Und wenn der Link-Count 0 ist _UND_ wenn kein offener Dateihandle mehr auf die Datei verweist, dann wird der Inode freigegeben. ==== man 2 unlink ==== unlink deletes a name from the filesystem. If that name ^^^^^^^(!) was the last link to a file and no processes have the file open the file is deleted and the space it was using is made available for reuse. If the name was the last link to a file but any processes still have the file open the file will remain in existence until the last file descriptor referring to it is closed. ==== Du kannst dir das so vorstellen: Das Dateisystem ist ein grosser Raum mit sehr vielen Schubladenschränken. Jede Schublade ist ein Inode wobei außen an der Lade groß die Inode-Nummer steht sowie klein die diversen Metainformation (aber kein Name!), v.a. aber auch der Link-Count. Wie findest du nun eine Datei? Und was sind Verzeichnisse? Die Inodes sind durchnummeriert, und einer ist noch als oberstes Verzeichnis gekennzeichnet (via Superblock des Dateisystems), stell es dir als großen Pfeil vor ;). Wenn du nun die Schublade des Verzeichnisses öffnest findest du als Inhalt ein Tabelle in der Name => Inodenummer (auch die der Unterverzeichnisse) steht. Über die Unterverzeichnisse kannst du dich zu jedem Namen durchhangeln. Irgendwann findest du dann die Tabelle mit dem gesuchten Dateinamen und somit die Inodenummer der richtigen Schublade mit den Daten. Und ein Hardlink ist einfach ein weiterer Eintrag in irgendeiner der Verzeichnistabellen. Und vielleicht kannst du dir jetzt eher vorstellen, daß es vollkommen irrelevant ist, in welchen und in wievielen (Verzeichnis-)Schubladen ein Tabelleneintrag mit ein und dem selben Inode steht. Und unter welchem Namen jeweils auf einen Inode verwiesen wird. Aber: jedesmal wenn man einen Eintrag in eine der Verzeichnistabellen einträgt muß man auch im Inode den Link-Count erhöhen bzw. beim Löschen erniedrigen... HTH, -dnh -- Wenn du beim Autofahren ein "komisches Geraeusch" hoerst und stehenbleibst (ohne das Geraeusch naeher identifizieren zu koennen!), dann schraubst du ja auch nicht einfach mal auf Verdacht an der Nockenwelle rum, wenn's doch nur am leeren Tank liegen koennte!
David Haller, Dienstag, 8. August 2006 21:58: [Viel Erklärung] Danke, David, das habe ich jetzt gut verstanden. Gibt es da einen prinzipiellen Unterschied zwischen verschiedenen Dateisystemen wie xfs, reiser, ext2/3? Und FAT/NTFS? Ich frage, weil ich unter Windows noch nie von Hardlinks gehört habe. -- Andre Tann
Hallo, Am Mit, 09 Aug 2006, Andre Tann schrieb:
David Haller, Dienstag, 8. August 2006 21:58: [Viel Erklärung]
Danke, David, das habe ich jetzt gut verstanden.
Sehr gut :)
Gibt es da einen prinzipiellen Unterschied zwischen verschiedenen Dateisystemen wie xfs, reiser, ext2/3?
Nicht in der Beziehung. Bei erweiterten Attributen usw. aber schon.
Und FAT/NTFS?
Ganz andere Baustelle. FAT ist komplett anders, NTFS hat stellenweise Ähnlichkeiten.
Ich frage, weil ich unter Windows noch nie von Hardlinks gehört habe.
Da gibt es irgendwas komisches, das irgendwie ähnlich funktioniert. Die Details interessieren mich aber nicht. -dnh -- "Ich weiß, daß ich paranoid bin. Die Frage ist nur: 'Bin ich paranoid genug?'"
2006/8/9, Andre Tann
Gibt es da einen prinzipiellen Unterschied zwischen verschiedenen Dateisystemen wie xfs, reiser, ext2/3? Und FAT/NTFS?
http://de.wikipedia.org/wiki/Harter_Link
Ich frage, weil ich unter Windows noch nie von Hardlinks gehört habe.
NTFS kann das. Windows aber nicht. :-) Gruß Martin
participants (7)
-
Andre Tann -
David Haller -
Dominik Klein -
Hubert Moesslein -
malcolm -
Martin Deppe -
Martin Schröder