The filesystems may contains huge sparse files (for example the docker
data file at path /var/lib/docker/devicemapper/devicemapper/data that is
100G big).
These files causes rsync to fail if the target file-system is too small
to copy them.
The option --sparse tells rsync to turn sequences of nulls into sparse
blocks.
--sparse, -S
Try to handle sparse files efficiently so they take up less
space on the destination. If combined with --inplace the file
created might not end up with sparse blocks with some
combinations of kernel version and/or filesystem type. If
--whole-file is in effect (e.g. for a local copy) then it will
always work because rsync truncates the file prior to writing
out the updated version.
Note that versions of rsync older than 3.1.3 will reject the
combination of --sparse and --inplace.
This adds the rsync short option -S to let rsync handle sparse files.
Fixes:
18:03:36 [6]: static CalamaresUtils::ProcessResult CalamaresUtils::System::runCommand(CalamaresUtils::System::RunLocation, const QStringList&, const QString&, const QString&, std::chrono::seconds)
Running "env" ("sync")
.. Finished. Exit code: 0
.. Target cmd: ("sync") output:
rsync: [receiver] write failed on "/tmp/calamares-root-81qie5d1/var/lib/docker/devicemapper/devicemapper/data": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(378) [receiver=v3.2.3]
Signed-off-by: Jeremy Whiting <jpwhiting@kde.org>
When testing with a / mountPoint set to subvolume: "" it tried and
failed to mount the subvolume:
.. Running ("mount", "-t", "btrfs", "-o", "subvol=,", "/dev/sda3", "/tmp/calamares-root-ylvhpxys/")
.. Target cmd: ("mount", "-t", "btrfs", "-o", "subvol=,", "/dev/sda3", "/tmp/calamares-root-ylvhpxys/") Exit code: 32 output:
mount: /tmp/calamares-root-ylvhpxys: wrong fs type, bad option, bad superblock on /dev/sda3, missing codepage or helper program, or other error.
This fix makes the following config in mount.conf let us drop out of any
subvolume handling:
btrfsSubvolumes:
- mountPoint: /
subvolume: ""
The Calamares Manager should not be a singleton; it is needed
in multiple threads (e.g. from QML). It can have a singleton
Private manager that caches and shares things, though.
