/rescue Größe???

[Ice]

Hi Leute,

ich bin eben per Zufall darüber gestolpert, dass die in /rescue liegenden Binaries nicht richtig summiert werden. System ist FreeBSD 5.4-p6.
Ein

du -sk /rescue

sagt mir

7422    /rescue

Seltsamerweise liegen aber in dem Verzeichnis ja eine ganze Menge, nämlich 139 Stück an der Zahl, statisch gelinkter Binaris, die fast alle absolut gleich groß, nämlich 3600KB groß sind und auch fast alle ein sehr hohe Linkanzahl (135) haben.
Ein

du -sh /rescue/*

liefert mir aber auch nur die Files, die kleiner sind und eine Linkanzahl von 1 haben.

3.5M    /rescue/[
8.0K    /rescue/dhclient-script
2.0K    /rescue/nextboot.sh
3.7M    /rescue/raidctl

Kann mir mal jemand dieses seltsame Verhalten ein bischen erläutern? Wozu ist denn das Binary "[" in dem Verzeichnis gut?

Wäre echt super, wenn da jemand meine Verwirrung etwas lichten könnte!

Thx,

Ice

 

[asg]

Ruf doch einfach mal "man [" auf ;-).
Und "man rescue" dann gleich auch noch...

 

[Ice]

Thx asg, Ouch, das war der nötige Klapps auf den Hinterkopf.......
Meine Frage zu "[" ist beantwortet, aber die Geschichte des Rescue-Systems erchließt sich mir noch immer nicht.....

Gruß,

Ice

 

[dagnu]

Die Datei "raidctl" findet sich nicht in meinem /rescue Verzeichnis. Ansonsten stimmt
die Ausgabe von "du -s" doch - es handelt sich bei all den binaries eigentlich nur um
ein einziges - siehe CRUNCHGEN(1):

A crunched binary is a program made up of many other programs linked together into a single executable.

 

[Ice]

Ich habe mir crunchgen auch schon angeschaut, aber irgendwie blick ich es trotzdem nicht wirklich. Ich habe jetzt mal spaßhalber das Verzeichnis mit rsync kopiert und siehe da: Auf einmal ist es 410MB groß.... Also irgendwie steh ich da wohl auf der Leitung....

Gruß,

Ice

 

[Elessar]

Okay, crunchgen erzeugt zwei Dateien (wenn man sich du -sk anschaut) mit ~3.3MByte, in der, statisch verlinkt, alle binaries drin sind, die man unterhalb von /rescue sieht. Um die Benutzung dieser Binarier zu erleichtern, gibt es dann Hardlinks für jede reingepacktes binary auf das crunched binary (zu hardlinks: man ln).

Wenn du das jetzt kopierst, wird es natürlich viel mehr (410MB), da nichtmehr verlinkt wird, sondern für jeden Eintrag kopiert.

'ls -li /rescue' zeigt dir auch sehr schön, dass alles unterhalb von /rescue in 2 inodes liegt.

 

[0815Chaot]

Das mit den Hardlinks und so sollte nun geklärt sein. Was mir aber daneben noch aufgefallen ist:

Ich habe jetzt mal spaßhalber das Verzeichnis mit rsync kopiert und siehe da: Auf einmal ist es 410MB groß...

Allerdings sollte rsync(1) die Hardlinks erhalten. Wenn der aus Hardlinks im Zielverzeichnis einzelne Dateien macht, ist das wohl nicht im Sinne des Erfinders.

Tipp: Wenn ihr das Zielverzeichnis auf eurem Rechner mounten könnt, dann tut das und verwendet zum Synchronisieren cpdup -v -i0 $QUELLE $ZIEL - sysutils/cpdup arbeitet wesentlich schneller als rsync(1) und erzeugt wirklich exakte Kopien. Allerdings geht das nur mit kompletten Verzeichnissen.

 

[Ice]

Thx, Elessar.
Der Hinweis auf die Inodes war Gold wert und hat den Knoten bei mir platzen lassen.

@0815Chaot
Das mit dem rsync war an dieser Stelle nur ein Test und das ist auch ok, wie das gelaufen ist, da rsync im Archiv-Modus keine Hardlinks erhält. Dazu wird die Option -H benötigt, die das dann übernimmt.

Alles in Allem hab ich es jetzt wenigstens richtig verstanden und das war mir die ein zwei kleinen Nasenstüber wert!

Gruß und Dank,

Ice