Re: mkisofs mastering sparse files - end result file full of zeros

[Graham Leggett]

On 24 Nov 2024, at 15:33, Thomas Schmitt <scdbackup@gmx.net> wrote:

Using mkisofs as packaged on Redhat Enterprise 9

They really should not simply call xorrisofs "mkisofs" ...

Been very careful to contact the correct place :)

No. Usually a reading program should see no difference between a sparse
file and a file that contains really written 0-bytes instead of the holes.

I made a mini test on an ext4 filesystem:

 $ echo hello | dd bs=1 seek=1G of=1gb_sparse
 6+0 records in
 6+0 records out
 6 bytes (6 B) copied, 0.0372587 s, 0.2 kB/s
 $ ls -l 1gb_sparse
 -rw-r--r-- 1 ... ... 1073741830 Nov 24 15:57 1gb_sparse
 $ du 1gb_sparse
 4       1gb_sparse

So my test file ist very sparse.

In the above case the whole file is 100% sparse, I suspect this is where it is going wrong.

In my case the file is a virtual machine image, so the file is mostly sparse (80%-90%), but does contain some data.

The original file starts like this:

[root@arnie vms]# hexdump -n 32 /home/backup/example/example.com/rsync/latest/var-lib-libvirt-images-snapshot/seb.example.com.qcow2

0000000 4651 fb49 0000 0300 0000 0000 0000 0000

0000010 0000 0000 0000 1000 0000 0200 0000 0000

0000020

Once mastered to the filesystem, burned, and then read back, the file starts like this:

[root@arnie vms]# hexdump -n 32 /home/backup/example/seb.example.com.qcow2 

0000000 0000 0000 0000 0000 0000 0000 0000 0000

*

0000020

Analysing the file shows the whole file is just zeros, beginning to end.

Is there a way to test this by creating a purely sparse file, and then concatenating it with another not-sparse file, and then check if the sha256 sigs are the same after the burn process? The checksums are different for me.

Regards,

Graham

--