kaputtnik
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
Hi! Sorry wenn ich hier poste, aber da ich im Zuge von Scriptarbeiten auf diese Problem gestossen bin... Versuche die Größe des Verzeichnisses /etc mittels du -hs /etc
#oder
du -bs /etc
#oder
du -ks /etc
#oder
du -ms /etc zu ermitteln. du -hs gibt was aus, was ich irgendwie nicht einordnen kann (wie kommt du auf diesen Wert?). Also mittels konqueror die Angaben überprüft und mittels krusader... und jedes Programm sagt was anderes! Ungültiges MakroDieses Makro ist nicht verfügbar
- Bilder
|
barcc
Anmeldungsdatum: 13. Juli 2007
Beiträge: 696
Wohnort: Dortmund
|
Hallo Ich hab das hier mal mit du und Nautilus getestet:
Nautilus: 2.639 Objekte der Gesamtgröße 9,1 MB
$ du -hs # belegter Festplattenplatz
15M /etc
$ du -hs --apparent-size /etc # Dateigrößen aufsummiert
9,3M /etc Der Unterschied zwischen 9,1 MB und 9,3M kommt daher, dass Nautilus versteckte Dateien und Ordner nicht mitzählt (.* und *~).
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
Du gibst auch explizit unterschiedliche Methoden zur Bestimmung der Größe an: man du ich würde bei /etc übrigens sudo davor setzen, um auch alle Dateien einzubeziehen. Außerdem, du und Konqueror sind sich doch einig. Beide haben ~8 * 1000 * 1000 Byte == 7,7 MiB
|
kaputtnik
(Themenstarter)
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
Ich lese man-Pages...nicht schon wieder dieser Vorwurf 🐸 Vllt werde ich manchmal nur nicht ganz schlau draus. Also: --apparent-size
print apparent sizes, rather than disk usage; although the
apparent size is usually smaller, it may be larger due to holes
in (‘sparse’) files, internal fragmentation, indirect blocks,
and the like
Dies ist nicht eine Aufsummierung, wie barcc schrieb, sondern die "scheinbare" Göße. Warum das manchmal größer oder manchmal kleiner ist, verstehe ich nicht so ganz. Zumindest einige Angaben verstehe ich nicht. Ein Zusammenfassung erhält man mit
-s, --summarize
display only a total for each argument
stfischr schrieb: Du gibst auch explizit unterschiedliche Methoden zur Bestimmung der Größe an:
Der einzige Unterschied zwischen -b und -k/m/h ist, das bei -b die Angabe --apparent-size automatisch berücksichtigt wird. Die Frage ist doch: Welche Ausgaben stimmen denn jetzt? Die mit --apparent-size oder die ohne? Ich meine n Unterschied von 5,7MB (in barccs Beispiel) ist doch schon recht groß. Bei meinem /home sinds dann schon 67 MiB:
$ sudo du -ms --apparent-size ~/
2930 /home/kaputtnik/
$ sudo du -ms ~/
2967 /home/kaputtnik/ Außerdem, du und Konqueror sind sich doch einig. Beide haben ~8 * 1000 * 1000 Byte == 7,7 MiB
Der Teiler von du ist doch auf 1024 voreingestellt ?! (i.ü.:MiB = Teiler 1024; MB = Teiler 1000)
--si like -h, but use powers of 1000 not 1024
--si verstehe ich so, das der Teiler 1024 voreingestellt ist, nicht 1000! ich würde bei /etc übrigens sudo davor setzen, um auch alle Dateien einzubeziehen.
Gut, das ist ein Argument... aber gerade in diesem Fall spielt es keine Rolle.
|
barcc
Anmeldungsdatum: 13. Juli 2007
Beiträge: 696
Wohnort: Dortmund
|
Dies ist nicht eine Aufsummierung, wie barcc schrieb, sondern die "scheinbare" Göße.
Beispiel:
echo -n abc >xyz
$ du -b xyz
3 xyz
# oder
$ du -h --apparent-size xyz
3 xyz
# Die Datei enthält 3 Bytes, das ist die "scheinbare" Größe
$ du -k xyz
4 xyz
# Die Datei besteht aus 4 "Blöcken" (ein Block 1024 B)
$ du -h xyz
4,0K xyz
# Die Datei belegt 4,0KiB (4 * 1024 B)
# 4096 ist die Blockgröße der Partition, d.h. jede Datei belegt ein Vielfaches von 4096 Bytes
$ du --si xyz
4,1k xyz
# Die Datei belegt 4,1 kB (4,1 * 1000 B), ist gerundet exakt wären es 4,196 KB
Wenn du ein Verzeichnis angibst und -sh --apparent-size verwendest, werden die Dateigrößen aufsummiert.
Warum das manchmal größer oder manchmal kleiner ist, verstehe ich nicht so ganz.
Meistens ist die "scheinbare" Größe kleiner weil ext2/ext3 eine feste Blockgröße verwendet. Kann man herausfinden mit sudo tune2fs -l /dev/sdc2 | grep 'Block size'
|
kaputtnik
(Themenstarter)
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
Hallo barcc, ja, da war ich jetzt auch soweit... aaaaber ich versuche die Größe eines Verzeichnisse (incl Inhalt) zu ermitteln, nicht die einer Datei. Soweit so gut... Nun aber der Beweis, das die Ausgaben von du (oder auch ls) für ein Verzeichnis keine Aussagekraft haben:
$ mkdir testdir
$ du -sh testdir
4,0K testdir
$ du -sh --apparent-size testdir
4,0K testdir
# Das Verzeichnis alleine benötigt einen Block, also 4096b. Jetzt erstellen wir viele Dateien im Verzeichnis...
$ cd testdir
$ for ((i=0; i<1000; i++)); do echo "testdatei" > testdatei_$i ; done # 1000 Dateien
$ ls -l testdatei_0
-rw-r--r-- 1 kaputtnik kaputtnik 10 2009-02-24 13:22 testdatei_0 # Jede Datei ist 10 Bytes Groß
# Im Verzeichnis sind also 1000 Dateien á 10 B = 10000 Bytes / 1024 = 9,77 KiB + 4 KiB fürs Verzeichnis selber(s.o.) = 13,77 KiB
# In Blöcken: Jede Datei verbraucht 1 Block * 1000 Dateien = 1000 Blöcke á 4096b = 4096000b / 1024 = 4000 KiB / 1024 = 3,9 MiB
# Diese Rechnung stimmt nicht, weil der Speicher für das Verzeichnis selber dynamisch verändert wird. ZB wird für die Dateinamen Platz benötigt.
# Somit geben die Programme auch nicht 13,77 Kib aus:
$ cd ..
$ du -sh testdir
4,0M testdir # etwa 1000 Blöcke
$ du -sh --apparent-size testdir
46K testdir # Summe Dateigröße 13,77 KiB + ? KiB Verzeichnis
$ ls -dl testdir
drwxr-xr-x 2 kaputtnik kaputtnik 36864 2009-02-24 13:22 testdir # Wo kommt diese Größe her?
# OK, nun löschen wir die Dateien wieder und gucken was mit der Verzeichnisgröße passiert:
$ cd testdir
$ rm testdatei_*
$ ls #Verzeichnis ist leer
$ cd ..
$ du -sh testdir
36K testdir
$ du -sh --apparent-size testdir
36K testdir
$ ls -dl testdir
drwxr-xr-x 2 franky franky 36864 2009-02-24 13:37 testdir
Beispiel abgewandelt aus: http://www.linuxquestions.org/questions/linux-newbie-8/directory-size-includes-size-of-..-604159/ Die Abfrage eines Verzeichnisses sagt nix darüber aus, welcher Platz belegt ist! Und nu?
|
adun
Anmeldungsdatum: 29. März 2005
Beiträge: 8606
|
kaputtnik schrieb: Die Abfrage eines Verzeichnisses sagt nix darüber aus, welcher Platz belegt ist! Und nu?
Du hast "Verzeichnis" wahrscheinlich falsch verstanden. Ein Verzeichnis ist eine Datei in der eine Liste von anderen Dateien der gleichen Partition liegt. Die Länge der Liste hat nicht unbedingt was mit der Größe der Dateien zu tun und ist in der Regel viel kleiner als die referenzierten Dateien. Der Denkfehler sollte klar werden, wenn du dir vor Augen führst, dass eine Datei in beliebig vielen Verzeichnissen liegen kann. Nehmen wir an eine Datei liegt in zwei Verzeichnissen, du dereferenzierst beide Verzeichnisse mit du, dann nimmt die Datei in deiner Wahrnehmung doppelt so viel Platz ein wie in "Wirklichkeit".
|
kaputtnik
(Themenstarter)
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
adun schrieb: kaputtnik schrieb: Die Abfrage eines Verzeichnisses sagt nix darüber aus, welcher Platz belegt ist! Und nu?
Du hast "Verzeichnis" wahrscheinlich falsch verstanden. Ein Verzeichnis ist eine Datei in der eine Liste von anderen Dateien der gleichen Partition liegt. Die Länge der Liste hat nicht unbedingt was mit der Größe der Dateien zu tun und ist in der Regel viel kleiner als die referenzierten Dateien.
Jo, das ist mit schon klar... Was ich möchte, ist eine verlässliche Ausgabe vom verbrauchten Speicherplatz. Wenn ich mit du eine Verzeichnis abfrage, habe ich eine summierte Größe aller darin enthaltenen Dateien erwartet. Anscheinend ist das aber nicht so. Wenn ich die Größe aller Dateien in allen Untzerverzeichnissen von /etc bekommen möchte, was muss ich dann tun? Alle Verzeichnisse "von Hand" durchgehen und jede Dateigröße per ls selber aufsummieren?
Der Denkfehler sollte klar werden, wenn du dir vor Augen führst, dass eine Datei in beliebig vielen Verzeichnissen liegen kann. Nehmen wir an eine Datei liegt in zwei Verzeichnissen, du dereferenzierst beide Verzeichnisse mit du, dann nimmt die Datei in deiner Wahrnehmung doppelt so viel Platz ein wie in "Wirklichkeit".
Verstehe ich nicht. Zwei Verzeichnisse: V1 und V2. In beiden liegt eine Datei D1 mit Größe 3KiB. Also ist V1 + V2 = 6 KiB + Verzeichnisliste von V1 und V2 Edit: Du meinst, die Datei ist in Wirklichkeit nur einmal vorhanden, wird aber in der Liste 2 mal aufgeführt?
|
Sid_Burn
Anmeldungsdatum: 23. Oktober 2004
Beiträge: 2159
|
Was ich möchte, ist eine verlässliche Ausgabe vom verbrauchten Speicherplatz. Wenn ich mit du eine Verzeichnis abfrage, habe ich eine summierte Größe aller darin enthaltenen Dateien erwartet. Anscheinend ist das aber nicht so. Wenn ich die Größe aller Dateien in allen Untzerverzeichnissen von /etc bekommen möchte, was muss ich dann tun? Alle Verzeichnisse "von Hand" durchgehen und jede Dateigröße per ls selber aufsummieren?
Man unterscheiden zwischen größe der Dateien und Speicherplatz verbrauch auf der Festplatte. Den wir haben ja noch ein sogenanntes Dateisystem das den Speicher einteilt. In der Regel hat man z.B. bei ext3 eine inode Größe von 4 KiB. Wenn eine Datei nun kleiner als 4KiB ist dann hat sie selber zwar nur sagen wir 20 Bytes, aber verbraucht die ganzen 4KiB auf der Festplatte. Da pro inode immer nur eine Datei zugeordnet werden kann. Mit "--apparent-size" bekommst du diese 20byte. Ohne summiert es den "echten" Festplattenplatzverbrauch der dann höher ist. "sparse" Dateien sind Dateien wo aufeinanderfolgende Nullen zusammengefasst werden. Wenn also 1.073.741.824 Nullen hintereinander in der Dateien stehen (1 GiB) würde bei einer sparse Datei nur die Info "1.073.741.824 * Nullen" stehen. also relativ wenig festplattenplatz verbrauch. Die Datei selber wird aber als 1 GiB größe angegeben. Dort ist also Dateigrößer, größer als Plattenverbrauch.
Der Denkfehler sollte klar werden, wenn du dir vor Augen führst, dass eine Datei in beliebig vielen Verzeichnissen liegen kann. Nehmen wir an eine Datei liegt in zwei Verzeichnissen, du dereferenzierst beide Verzeichnisse mit du, dann nimmt die Datei in deiner Wahrnehmung doppelt so viel Platz ein wie in "Wirklichkeit".
Verstehe ich nicht. Zwei Verzeichnisse: V1 und V2. In beiden liegt eine Datei D1 mit Größe 3KiB. Also ist V1 + V2 = 6 KiB + Verzeichnisliste von V1 und V2 Edit: Du meinst, die Datei ist in Wirklichkeit nur einmal vorhanden, wird aber in der Liste 2 mal aufgeführt?
Genau Unix Basierte Dateisysteme unterstützen ja Hardlinks und Softlinks. Mit Hardlinks hast du eine Technik das du eine Datei einmal auf der Festplatte hast. Aber die gleiche Datei aus verschiedenen Ordnern Referenziert wird. Die Datei existiert damit nur einmal auf der Festplatte und verbraucht sagen wir 1 GiB. Wenn du sie aber zweimal referenzierst und dann zählst dann würde er 2 GiB aufzählen obwohl nur 1GiB auf der Festplatte verbrauch wird an Speicher. Bei zwei unterschiedlichen Dateien mit deinem beispiel wäre z.B. 6KiB Platzverbrauch durch die Datei, und 8KiB Festplattenverbrauch wegen zwei inodes. Wäre die inode größe auf 32KiB oder 64KiB eingestellt (höhere lese performance bei großen dateien) dann würde er bereits 64 KiB oder 128 KiB Festplattenspeicher verbrauchen. EDIT: Beispiel:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | #!/usr/bin/perl
# Core Modules
use strict;
use warnings;
my $one_mib = 'x' x 1024 x 1024;
open my $fh, '>', 'test.txt' or die $!;
for ( 1 .. 1024 ) {
print {$fh} $one_mib or die $!;
}
close $fh or die $!;
for ( 1 .. 1024 ) {
link 'test.txt', "test_$_.txt";
}
|
Das ganze erstellt dir eine einzige 1GiB grosse Datei, verlinkt sie danach 1024 mal. Je nachdem welches programm du nutzt (z.B. Nautilus) wird die dann sagen das der Ordner 1TiB groß ist. Du kannst den Ordner ohne Probleme erstellen, musst nur 1 GiB Speicher frei haben, deine Partition muss keine 1 TiB groß sein damit das klappt. Wenn du das ganze kopierst wird daraus aber wirkliche 1TiB...
|
adun
Anmeldungsdatum: 29. März 2005
Beiträge: 8606
|
kaputtnik schrieb: In beiden liegt eine Datei D1 mit Größe 3KiB.
Genau das meine ich. Dateimanager vermitteln das Bild, Dateien würden in Verzeichnissen liegen. Wenn du das aber so wie hier genau ergründen willst, musst du feststellen, dass das nicht stimmt. Verzeichnisse sind eher Henkel an Dateien und eine Datei kann viele Henkel haben, wobei nicht alle Verzeichnisse sein müssen. Es gibt Dateien, die kein Verzeichnis haben und wie schon ausgeführt welche die viele haben. Du hast ja noch nicht gesagt was du mit der Information anfangen willst, die du versuchst aus einem Verzeichnis zu bekommen. Ich wollte dem nur schon mal vorgreifen und dich davor warnen, falsche Schlüsse aus deinen Angaben zu ziehen. Auch wenn du "kopieren" willst, musst du aufpassen. Ich hab z.B. eine XFS Partition mit sehr großen Blöcken, weil XFS ne Krise kriegt bei vielen Blöcken pro realem Speicher. Die Angabe was das irgendwo anders real verbraucht ist da ziemlich nutzlos.
|
kaputtnik
(Themenstarter)
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
Ja gut, das mit den Blöcken und das Dateien nicht immer einen Block ausfüllen, das habe ich ja schon gecheckt. Weiter:
Sid Burn schrieb: Mit "--apparent-size" bekommst du diese 20byte. Ohne summiert es den "echten" Festplattenplatzverbrauch der dann höher ist.
Nochmal zu meinem Beispiel von vorher: Ich erstelle ein Verzeichnis "testdir" und guck mir die Größe mit du an:
$ du -sh --apparent-size testdir
4,0K testdir
Dann fülle ich das Verzeichnis mit Dateien und lösche sie wieder. Dann guck ich nochmal das Verzeichnis mit du an:
$ du -sh --apparent-size testdir
36K testdir
Tja, schade, das Verzeichnis ist leer aber du zeigt mir 32 KiB mehr an als vorher. Woran das liegt weiß ich ja schon, die Frage ist: Wie bekomme ich jetzt die tatsächliche Größe des Verzeichnisses (des Inhalts) angezeigt? Das mit den Hard- und SoftLinks ist auch sehr interessant, aber hat irgendwie nichts mit meinem Problem zu tun... weil ich zB in meinem Beispiel keine Hardlinks benutze. Es kann natürlich sein, das in anderen Verzeichnisse solche Links gesetzt sind, aber dann soll er die auch ruhig mitzählen.
|
kaputtnik
(Themenstarter)
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
adun schrieb: Auch wenn du "kopieren" willst, musst du aufpassen. Ich hab z.B. eine XFS Partition mit sehr großen Blöcken, weil XFS ne Krise kriegt bei vielen Blöcken pro realem Speicher. Die Angabe was das irgendwo anders real verbraucht ist da ziemlich nutzlos.
Ein Problem beim Kopieren dürfte ja sein, das andere Speichermedien andere Blockgrößen haben ... aber dann sind doch beide Angaben ("reele Größe" und "Größe der verwendeten Blöcke") irgendwie nicht aussagekräftig. Oder steh ich da jetzt schon wieder aufm Schlauch 😕 ?
|
Sid_Burn
Anmeldungsdatum: 23. Oktober 2004
Beiträge: 2159
|
kaputtnik schrieb: Dann fülle ich das Verzeichnis mit Dateien und lösche sie wieder. Dann guck ich nochmal das Verzeichnis mit du an:
Tja, schade, das Verzeichnis ist leer aber du zeigt mir 32 KiB mehr an als vorher. Woran das liegt weiß ich ja schon, die Frage ist: Wie bekomme ich jetzt die tatsächliche Größe des Verzeichnisses (des Inhalts) angezeigt?
Hmm, keine Ahnung aber bei mir ist das nicht so!
Wenn ich den Ordner fülle und lösche dann ist er danach wieder nur 4KiB groß. Wie löscht du die Dateien den? Bei Nautilus war es eine Zeitlang so das er die Dateien im gleichen Ordner beläst nur in einen Versteckten Ordner ".Trash" verschiebt. Daher die Dateien sind noch immer da, nur verschoben. Die Dateigröße bleibt also. Glaube mitlerweile verschiebt er das irgendwo anders im home Verzeichnis hin, aber kann ja auch sein das du was anderes nutzt (also anderen Filebrowser). Was zeigt den ein "ls -a" nach dem löschen im Ordner an?
Das mit den Hard- und SoftLinks ist auch sehr interessant, aber hat irgendwie nichts mit meinem Problem zu tun... weil ich zB in meinem Beispiel keine Hardlinks benutze. Es kann natürlich sein, das in anderen Verzeichnisse solche Links gesetzt sind, aber dann soll er die auch ruhig mitzählen.
Das ganze war ja nur eine erklärung wie unterschiedliche größen zustande kommen können.
Auch wenn du "kopieren" willst, musst du aufpassen. Ich hab z.B. eine XFS Partition mit sehr großen Blöcken, weil XFS ne Krise kriegt bei vielen Blöcken pro realem Speicher. Die Angabe was das irgendwo anders real verbraucht ist da ziemlich nutzlos.
Hmm, hast du darüber mal mehr Infos? Ich selber wollte demnächst mal auf XFS umsteigen, in bisherigen Test von mir lief es auch sehr gut. Mit Standard Einstellungen (unter Debian). Denke es war auch 4KiB Blockgröße. Wenn XFS aber "Probleme" hat mit kleinen Blockgrößen wäre das nett es vor dem Umstellen zu Wissen, so das ich nicht alles dreimal machen muss.
|
kaputtnik
(Themenstarter)
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
Sid Burn schrieb: Wie löscht du die Dateien den? Bei Nautilus war es eine Zeitlang so das er die Dateien im gleichen Ordner beläst nur in einen Versteckten Ordner ".Trash" verschiebt. Daher die Dateien sind noch immer da, nur verschoben. Die Dateigröße bleibt also. Glaube mitlerweile verschiebt er das irgendwo anders im home Verzeichnis hin, aber kann ja auch sein das du was anderes nutzt (also anderen Filebrowser). Was zeigt den ein "ls -a" nach dem löschen im Ordner an?
Hab mit rm gelöscht. Genauso wie oben beschrieben. Es geht mir immer noch um die Ermittlung einer zu sichernden Datenmenge:http://forum.ubuntuusers.de/post/1846695/ Die Version dort haut irgendwie immer noch nicht hin.. eben wegen den Größenangaben.
|
barcc
Anmeldungsdatum: 13. Juli 2007
Beiträge: 696
Wohnort: Dortmund
|
kaputtnik schrieb: Tja, schade, das Verzeichnis ist leer aber du zeigt mir 32 KiB mehr an als vorher. Woran das liegt weiß ich ja schon, die Frage ist: Wie bekomme ich jetzt die tatsächliche Größe des Verzeichnisses (des Inhalts) angezeigt?
Wenn nur die Größe von regulären Dateien (keine Verzeichnisse, symbolische Links, devices, ... ) angezeigt werden sollen, könnte man das zB so machen:
du -hc --apparent-size --files0-from=<(find -P /etc -xtype f -print0)
oder, wenn du nur die Gesamtsumme haben willst:
du -hc --apparent-size --files0-from=<(find -P /etc -xtype f -print0 2>/dev/null) | tail -n 1
|