Software::Systemverwaltung
Kopieren von Dateien unter Linux könnte schneller werden
Eine Diskussion unter den Kernel-Entwicklern zeigte auf, dass das Kopieren von Dateien nicht immer so schnell ist, wie es sein könnte. Die Ursachen dafür sind allerdings weniger im Kernel zu verorten, sondern überwiegend in den Anwendungsprogrammen, die die vorhandenen Möglichkeiten nicht voll nutzen.
Larry Ewing
Das Kopieren (von Dateien) ist eine der am häufigsten genutzten Funktionen überhaupt. Ein Großteil der Arbeit, die ein Benutzer am Rechner durchführt, hat Kopiervorgänge als Bestandteil. Aus diesem Grund sind Kopiervorgänge im Kernel hoch optimiert, über die Jahre und Jahrzehnte wurden sie immer weiter verbessert und können in der Regel die höchste Geschwindigkeit erzielen, die die Hardware zulässt.
Dennoch besteht noch Raum für Verbesserungen. Daher wurde das Thema auf dem 2019 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM), der vom 30. April bis 2. Mai in San Juan, Puerto Rico stattfand, von Steve French noch einmal aufgegriffen. Er präsentierte zunächst einige Benchmarks, bei denen scp und rsync bei lokalen Kopien deutlich langsamer waren als cp. Ein Grund dafür soll sein, dass cp eine Puffergröße von 128 KB verwendete, die anderen Werkzeuge nur 16 KB. Laut French könnte schon eine Erhöhung der Puffergröße auf 1 MB oder gar mehrere MB die Geschwindigkeit steigern. Das würde allerdings auch den Speicherbedarf der Anwendung erhöhen. Zusätzlich ist es für Anwendungen derzeit nicht leicht, die optimale Größe für Ein- und Ausgaben zu ermitteln. Ob es dafür einmal eine bessere Methode geben wird, ist noch offen.
Die unter Linux hauptsächlich genutzten Programme, cp (aus den GNU Coreutils), scp (aus dem OpenSSH-Paket) und rsync dagegen könnten deutlich schneller sein. Das Problem ist bei Anwendern, die großen Wert auf die Geschwindigkeit legen, bereits lange bekannt und führte bereits zu zahlreichen optimierten Programmen, wie French anführte. French listete einige Programme auf und erwähnte auch eine Arbeit der NASA, die cp beschleunigte. Doch diese Verbesserung wurde nie in die offizielle Version übernommen.
Die Diskussion drehte sich besonders um die Frage, ob seitens des Linux-Kernels noch etwas zu verbessern wäre. Dies wurde aber großteils verneint, allerdings gibt es Ausnahmen. So fehlt in Btrfs noch die Funktion copy_file_range. Mit dieser Funktion könnte Btrfs das Kopieren optimieren.
Ein Problem für viele Anwender ist es, das Erzeugen einer neuen Datei und das Setzen von erweiterten Attributen und ACLs korrekt auszuführen. Laut Ted Ts'o wäre es hilfreich, eine Bibliothek zu haben, die von den Benutzern einfach eingebunden werden kann. Auch hier bleibt zunächst offen, ob jemand eine solche Bibliothek entwickelt.
Es kann unter Umständen nützlich sein, beim Kopieren den Seiten-Cache zu umgehen. Denn die Verwaltung des Caches kostet Zeit und verdrängt möglicherweise andere Seiten aus dem Speicher. In den Programmen könnte dies durch die Verwendung von O_DIRECT implementiert werden. Laut French würde es zusätzlich einige Prozent Geschwindigkeit bringen. Allerdings hängt es von der Anwendung ab, ob die Option nützlich ist. Wenn die Daten kurz nach dem Kopieren verwendet werden sollen, ist es besser, den Seiten-Cache zu nutzen. Die Programme müssten also dem Benutzer die Wahl ermöglichen.
Nicht in der Diskussion, aber in den Kommentaren zum Artikel wurde der Systemaufruf sendfile erwähnt, der explizit zur Beschleunigung von Kopiervorgängen geschaffen wurde und sicher auch cp erheblich Beine machen würde. Doch ein entsprechender Vorschlag wurde 2012 von den GNU-Entwicklern verworfen, da sendfile noch nicht allgemein zur Verfügung stand und die Erkennung dieses Sachverhalts den Code von cp komplizierter gemacht hätte. Es wäre sicherlich an der Zeit, diese Haltung zu hinterfragen.
Es bleibt als Fazit, dass die wichtigsten Werkzeuge zum Kopieren - cp, scp und rsync - die Möglichkeiten des Kernels nicht ausnutzen, die bereits lange existieren und immer weiter verbessert werden. Wem diese Werkzeuge daher zu langsam sind, der wird wohl eigene Benchmarks vornehmen und sich ein anderes Werkzeug suchen oder eines der genannten modifizieren müssen. Die aktuelle Situation kann damit nicht als befriedigend bezeichnet werden.
){kind=small}
