On 7/6/20 3:44 PM, Richard W.M. Jones wrote:
>
> Does this always work even when the tar file was created with sparse
> file support? For that matter, if the tar file was created with
> sparse file contents, are we even guaranteed that a contiguous
> offset of the tar file is blindly usable as the data to serve?
We've used the same technique on thousands of OVA files without
hitting any problem so far, so I guess that ...
> $ truncate --size=1M large
> $ echo 'hi' >> large
> $ tar cSf f.tar large
> $ ls -l large f.tar
> -rw-rw-r--. 1 eblake eblake 10240 Jul 6 13:57 f.tar
> -rw-rw-r--. 1 eblake eblake 1048579 Jul 6 13:48 large
> $ LANG=C tar --no-auto-compress -tRvf f.tar large
> block 0: -rw-rw-r-- eblake/eblake 1048579 2020-07-06 13:48 large
> block 2: ** Block of NULs **
>
> Yep, we need to special-case sparse tar files :(
.. OVAs don't use this feature. I wonder if it's a GNU feature?
-S exists in both gtar and in star (Joerg Schilly's tar [1]; Joerg often
complains on the GNU tar mailing list that his 'star' is more powerful
than GNU tar), but sparse support is indeed missing in other tar
implementations (technically, POSIX only specifies 'pax', not 'tar' [2],
although the underlying data format is supposed to be compatible enough,
and pax lacks -S...).
[1]
https://docs.oracle.com/cd/E71197_01/SAMCR/star.1m.htm
[2]
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org