Wie berechnet man die Gesamtgröße eines Verzeichnisses und warum unterscheidet sich die `du`-Ausgabe zwischen den Kopien des Verzeichnisses?

Question 1

Vergessen Sie nicht, dass dudie Festplattennutzung auf der Ebene des zugrunde liegenden Dateisystems gemeldet wird, nicht auf der scheinbaren "Dateigröße" Ebene ... siehe --apparent-size.

--apparent-size

gibt die scheinbare Größe aus, nicht die Festplattennutzung; obwohl die scheinbare Größe normalerweise kleiner ist, kann sie aufgrund von Löchern in ('sparse') Dateien, interner Fragmentierung, indirekten Blöcken und dergleichen größer sein

Siehe auch -b, was eine bessere Option sein könnte, als zu geben--block-size=1 Und --apparent-sizezusammen:

-b,--bytes

gleichwertig--apparent-size --block-size=1

... führt das also du -bs ${dir}zu besseren Ergebnissen?

Da die meisten/alle Dateisysteme auf Blöcken mit fester Größe basieren, ist es sehr üblich, das scheinbare „Dateigröße" (d. h. die Anzahl der Bytes, die Sie aus einer Datei lesen könnten) unterscheidet sich vom tatsächlich auf der Festplatte belegten Speicherplatz (d. h. der Anzahl der Bytes, die zum Speichern dieser Datei und ihrer Metadaten verbraucht werden).

Zum Beispiel:

Kleine Dateien benötigen in der Regel mehr Speicherplatz als sie "sollen„… auf einem Dateisystem mit 4-KiB-Blöcken ist es nicht möglich, dass eine Datei weniger als 4 KiB Speicherplatz belegt, selbst wenn sie nur ein Byte speichert.
Große Dateien bestehen üblicherweise aus einer Anzahl von "Ausmaße„... ein Extent beschreibt, wo die Daten für einen Teil der Datei zu finden sind. Extents verbrauchen ebenfalls Speicherplatz.
- In einem Dateisystem ohne Fragmentierung (d. h. mit großen Lücken ungenutzten Speicherplatzes) ist es möglich, dass ein „groß" Datei mit nur einem Extent.
- In einem Dateisystem mit starker Fragmentierung (d. h. viele Daten überall verstreut, mit kleinen Lücken zwischen den Daten) kann dasselbe "groß"-Datei kann tatsächlich mehrere Extents haben, die angeben, wo die Daten gespeichert sind.

Dies hängt ganz von der Reihenfolge ab, in der die Dateien auf der Festplatte abgelegt werden, und von den Algorithmen, die zum Auffinden zusammenhängender Blöcke freien Speicherplatzes verwendet werden.

Sie könnten ein sehr platzsparendes Dateisystem haben, das alle Dateien kontinuierlich und sorgfältig neu anordnet, sodass sie perfekt mosaikartig angeordnet sind wie ein gut gespieltes Tetris-Brett. Das Dateisystem würde letztendlich viel Zeit mit der Suche nach geeignetem Speicherplatz verbringen und die Leistung würde drastisch darunter leiden.

Ebenso könnten Sie ein stark fragmentierungsorientiertes Dateisystem haben, das nur die ersten unbenutzten Blöcke verwendet und bereits verwendete Blöcke überspringt. Das Schreiben von Daten auf First-Gap-Basis wird Ihre Leistung ebenfalls beeinträchtigen.

Stattdessen ziehen wir es vor, die Dinge auszugleichen, indem wirmancheZeit (aber nicht zu viel), um einen zusammenhängenden Block ungenutzten Speicherplatzes zu suchen, der alle Daten enthält, die wir schreiben möchten.

Der Fragmentierungsgrad einer Datei ist nicht direkt an die Reihenfolge gebunden, in der die Kopierbefehle ausgegeben wurden - teilweise aufgrund der "versuchen, aber nicht zu hart"-Ansatz, der oben beschrieben wurde.

Zusammenfassend sollten die in diesen beiden Verzeichnissen gespeicherten Daten gleich sein, aber die Festplattennutzung (auch fürdie gleichen Daten) ist wahrscheinlich nicht perfekt passend.

Um zu prüfen, ob die gespeicherten Daten identisch sind, stehen mehrere Möglichkeiten zur Verfügung. Versuchen Sie es diff(keine Ausgabe ist gut, die Änderungen werden gemeldet):

diff -qr "${src}" "${dst}"

Um dies noch komplizierter zu machen, ist es möglich, dass Sparse-Dateienbedeutendweniger als erwartet:

$ truncate -s 100M x
$ ls -l x
-rw-r--r-- 1 attie attie 104857600 Jul 14 17:15 x
$ du --block-size 1 x
0       x
$ du -bs x
104857600       x

Answer