In 8 Jahren hat sich viel verändert.
Fallokation
fallocate -d filename kann verwendet werden, um Löcher in vorhandene Dateien zu stanzen. Aus dem fallocate(1) Manpage:
-d, --dig-holes
Detect and dig holes. This makes the file sparse in-place,
without using extra disk space. The minimum size of the hole
depends on filesystem I/O block size (usually 4096 bytes).
Also, when using this option, --keep-size is implied. If no
range is specified by --offset and --length, then the entire
file is analyzed for holes.
You can think of this option as doing a "cp --sparse" and then
renaming the destination file to the original, without the
need for extra disk space.
See --punch-hole for a list of supported filesystems.
(Diese Liste:)
Supported for XFS (since Linux 2.6.38), ext4 (since Linux
3.0), Btrfs (since Linux 3.7) and tmpfs (since Linux 3.5).
tmpfs auf dieser Liste finde ich am interessantesten. Das Dateisystem selbst ist effizient genug, um nur so viel RAM zu verbrauchen, wie es zum Speichern seiner Inhalte benötigt, aber die Inhalte zu erstellen Sparse kann diese Effizienz möglicherweise noch weiter steigern.
GNU cp
Außerdem irgendwo auf dem Weg GNU cp Ein Verständnis für Sparse-Dateien erlangt. Zitieren des cp(1) Manpage bezüglich des Standardmodus --sparse=auto :
Sparse-SOURCE-Dateien werden durch eine grobe Heuristik erkannt und die entsprechende DEST-Datei wird ebenfalls spärlich gemacht.
Aber es gibt auch --sparse=always , wodurch das Dateikopieäquivalent von fallocate -d aktiviert wird funktioniert an Ort und Stelle:
Geben Sie --sparse=always an um eine DEST-Datei mit geringer Dichte zu erstellen, wenn die SOURCE-Datei eine ausreichend lange Folge von Null-Bytes enthält.
Endlich konnte ich meinen tar cpSf - SOURCE | (cd DESTDIR && tar xpSf -) in Rente schicken Einzeiler, was 20 Jahre lang meine Art war, spärliche Dateien zu kopieren, wobei ihre Spärlichkeit erhalten blieb.
Einige Dateisysteme unter Linux / UNIX haben die Fähigkeit, "Löcher" in eine vorhandene Datei zu schlagen. Siehe:
- LKML-Posting über die Funktion
- FAQ zum Abschneiden von UNIX-Dateien (suchen Sie nach F_FREESP)
Es ist nicht sehr tragbar und wird nicht überall auf die gleiche Weise durchgeführt. Im Moment glaube ich, dass die IO-Bibliotheken von Java keine Schnittstelle dafür bieten.
Wenn Lochen verfügbar ist, entweder über fcntl(F_FREESP) oder über einen anderen Mechanismus, sollte es deutlich schneller sein als eine Kopier-/Suchschleife.
Ich denke, Sie wären besser dran, die gesamte Datei vorab zuzuordnen und eine Tabelle/BitSet der belegten Seiten/Abschnitte zu pflegen.
Das Erstellen einer Datei mit geringer Dichte würde dazu führen, dass diese Abschnitte fragmentiert würden, wenn sie jemals wiederverwendet würden. Vielleicht ist das Einsparen von ein paar TB Speicherplatz den Leistungseinbruch einer stark fragmentierten Datei nicht wert.