Closed stoneshi-yunify closed 3 years ago
Looks like a useful enhancement. Care to prepare a PR?
One thing to watch out for is how much larger images become when installing cp from coreutils.
/help
/assign
/remove-help
The tar
hostpath used for snapshot/restore doesn't support sparse file either. It will treat the sparse file as regular file, so the process is very slow and the resulting file is usually huge. We may use GNU tar with the --sparse
flag instead.
The
tar
hostpath used for snapshot/restore doesn't support sparse file either. It will treat the sparse file as regular file, so the process is very slow and the resulting file is usually huge. We may use GNU tar with the--sparse
flag instead.
The GNU tar may not be adopted as GNU cp. When testing with the sparse file with IO (e.g. a running kubevirt virtual machine), the GNU tar command often returns exit code 1 instead of exit code 0, as described in manpage of GNU tar:
RETURN VALUE
Tar exit code indicates whether it was able to successfully perform the requested operation, and if not, what kind of error
occurred.
0 Successful termination.
1 Some files differ. If tar was invoked with the --compare (--diff, -d) command line option, this means that some files in
the archive differ from their disk counterparts. If tar was given one of the --create, --append or --update options,
this exit code means that some files were changed while being archived and so the resulting archive does not contain the
exact copy of the file set.
2 Fatal error. This means that some fatal, unrecoverable error occurred.
If a subprocess that had been invoked by tar exited with a nonzero exit code, tar itself exits with that code as well. This can
happen, for example, if a compression option (e.g. -z) was used and the external compressor program failed. Another example is
rmt failure during backup to a remote device.
Even we bypassed the the exit code 1 (treat it as success), after snapshot restore (tar -Szf
), the resulting sparse file failed to start a kubevirt virtual machine. Using bubybox tar does not have this issue. So there must be some important metadata lost during snapshoting/restoring when using GNU tar.
Consider this reason, I think it's not ready to change the tar to GNU tar.
Hostpath: v1.6.2
Cloning volume will call
cp -a <src-vol> <dest_vol>
, refer to https://github.com/kubernetes-csi/csi-driver-host-path/blob/e4d72e308439144cdd996cbb7e22f8ca0a965474/pkg/hostpath/hostpath.go#L480.The cp from Alpine by default doesn't support sparse file, it will copy a sparse file as a regular file. Therefore, if the source volume has a large sparse file, the cp will be extremely slow.
A QEMU/VM disk image is a kind of sparse file we usually see, projects like kubevirt them a lot.
The cp from coreutils supports sparse file by default, and will extremely shorten the copying time. So hostpath may just install the coreutils.
The cp test: