bsdtar vs gnu tar - arquivos esparsos

Question

Eu tenho trabalhado com imagens raw do qemu e acabei de fazer algumas perguntas sobre o uso do tar com elas.

Pelo que eu li, o bsdtar com o kernel > = 3.1 é capaz de lidar com os arquivos de imagens esparsas muito mais rápido que o gnu tar, porque ele pode tirar proveito da funcionalidade seek_hole no kernel. Eu testei e é significativamente mais rápido que o tar.

Minha pergunta é esta ... meu arquivo de imagem (tamanho original) é 260G. Como não está cheio e é esparso, só ocupa 38G. Quando faço um tar -cvSf test.img.tar test.img , demora muito (~ 10 minutos), mas acabo com um arquivo de 20G. Se eu descompactar, ele volta para 38G. Quando eu faço um bsdtar -cvf test.img.tar test.img it vai muito mais rápido (~ 2,5 minutos), mas o tamanho do arquivo é 38G do 20G que o gnu tar me deu.

Qual é a diferença? Por que o tamanho do arquivo é menor com tar? Eu esperaria que o comportamento fosse parecido com o que o bsdtar fez porque eu pensei que o tar -S só forçava o tar a tratar o arquivo como um arquivo esparso e não expandi-lo, então não entendo por que ele é menor.

Obrigado antecipadamente!

    

Answer 1

Do manual do GNU alcatrão (info):

8.1.2 Archiving Sparse Files

Files in the file system occasionally have "holes". A "hole" in a file is a section of the file's contents which was never written. The contents of a hole reads as all zeros. On many operating systems, actual disk storage is not allocated for holes, but they are counted in the length of the file. If you archive such a file, 'tar' could create an archive longer than the original. To have 'tar' attempt to recognize the holes in a file, use '--sparse' ('-S'). When you use this option, then, for any file using less disk space than would be expected from its length, 'tar' searches the file for consecutive stretches of zeros. It then records in the archive for the file where the consecutive stretches of zeros are, and only archives the "real contents" of the file. On extraction (using '--sparse' is not needed on extraction) any such files have holes created wherever the continuous stretches of zeros were found. Thus, if you use '--sparse', 'tar' archives won't take more space than the original.

'-S' '--sparse' This option instructs 'tar' to test each file for sparseness before attempting to archive it. If the file is found to be sparse it is treated specially, thus allowing to decrease the amount of space used by its image in the archive.

This option is meaningful only when creating or updating archives. It has no effect on extraction.

Consider using '--sparse' when performing file system backups, to avoid archiving the expanded forms of files stored sparsely in the system.

Even if your system has no sparse files currently, some may be created in the future. If you use '--sparse' while making file system backups as a matter of course, you can be assured the archive will never take more space on the media than the files take on disk (otherwise, archiving a disk filled with sparse files might take hundreds of tapes). *Note Incremental Dumps::.

However, be aware that '--sparse' option presents a serious drawback. Namely, in order to determine if the file is sparse 'tar' has to read it before trying to archive it, so in total the file is read twice. So, always bear in mind that the time needed to process all files with this option is roughly twice the time needed to archive them without it.

When using 'POSIX' archive format, GNU 'tar' is able to store sparse files using in three distinct ways, called "sparse formats". A sparse format is identified by its "number", consisting, as usual of two decimal numbers, delimited by a dot. By default, format '1.0' is used. If, for some reason, you wish to use an earlier format, you can select it using '--sparse-version' option.

'--sparse-version=VERSION'

Select the format to store sparse files in. Valid VERSION values are: '0.0', '0.1' and '1.0'. *Note Sparse Formats::, for a detailed description of each format.

Using '--sparse-format' option implies '--sparse'.

(ênfase adicionada)

Ou seja, é mais lento porque lê o arquivo (s) duas vezes; pela primeira vez para analisar o conteúdo do arquivo, segunda vez para realmente arquivá-los.
Essa abordagem para detectar a dispersão provavelmente também explica por que o arquivo é ainda menor; É bem provável que existam seqüências significativas de zeros que não são armazenadas esparsamente.