Ausgangssituation: Ubuntu mit BTRFS-Layout @, @home, @data. Von diesem werden in einem Ordner des root-Volumes per Skript readonly-Snapshots erstellt. Dazu kommt dann noch eine rsync-Kopie der Boot-Partition, ein dd des mbr und das Partitionslayout von sgdisk. Das ganze wird dann in ein Squashfs gepackt. Die resultierende Datei ist dann so ca. 50 GB groß, obwohl da noch mehrere virtuelle Linuxe mit dabei sind. Soweit so "effizient". Wenn mal was schiefgeht, lässt sich das Squashfs nämlich mounten und man kann alle alten Daten und Konfigs wieder erlangen...
Angenommen dieses Squashfs wird auf einer externen 2TB-Notebook-Platte erstellt. Sie ist in zwei Partitionen unterteilt, das vordere "schnelle" Terabyte (ca 120-80 MB/s) sei ein btrfs, das hintere "langsame" Terabyte (ca.80-60 MB/s) sei ein XFS. Weil btrfs halt cool ist, aber es könnte - wie gerade bei Fedora mit Kernel 3.19.3 passiert - ja auch noch Bugs haben. Also lieber noch mal eine Kopie auf etwas bewährtem haben. Wenn das schnelle Terabyte nach ein paar Wochenbackups voll ist, werden die alten auf das langsame verschoben. Und da eine Platte ja mal kaputt gehen könnte, werden halt zwei oder drei Platten mit dieser Strategie im Wechsel verwendet. Es ist also KEINE Lösung, das alte Backup von der einen auf die andere zu schieben, eine der beiden Platten ist ggf. "offsite" weit weg...
Nun ist diese Backup-Platte als Notebook-Platte ja besonders schlecht bei den Zugriffen "seek time". Während sich das Backup von der SSD auf die Platte noch mit 100 MB/s erstellen lässt (CPU schafft ca. Kompressionsrate um die Platte zu sättigen), schafft das anschließende Kopieren vom äußeren auf das innere Terabyte nicht etwa 50% also 50-30 MB/s sondern nur knapp 20 MB/s. Der Rest wird durch das ständige Umpositionieren des Schreib/Lesekopfes verbraten, während ein "cp -a /mnt/btrfs-außen/desktop@2015-irgendwas /mnt/xfs-innen" läuft.
Mein Ansatz das ganze zu beruhigen und die Kopfbewegungen zu minimieren (auch um Backup-Platte zu schonen), war ein python-Skript, dass einstellbar (500M...10G...) "große" Chunks/Scheiben der Datei in den RAM liest und wieder rausschreibt. Geht, ist aber nicht so flott wir erhofft, aber immer noch besser als vorher.
Die Frage ist, ob einer der üblichen Verdächtigen (tar?) oder sonst ein Bordmittel existiert, dem man beibringen kann, nicht alle x Sekunden die gelesenen Daten rauszuschreiben, eben WEIL man auf der selben Spindel unterwegs ist. Ich denke hier vlt. auch an eine pipe mit pv oder was ähnliches... Wäre ein neues Feature für Linux: adaptives I/O: wenn hohe Latenzen, weil HDD und nicht SSD und Datei groß, dann in Größenordnung tmpfs RAM 1/2 in Chunks kopieren?. Kann man das gar iwo einstellen?