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

[Graham Leggett]

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

Once mastered to the filesystem, burned, and then read back,

Which program runs with which arguments exactly did you perform ?

(I still have to emphasize that the way how libisofs reads files should
not be affected by the way how the local filesystem stores the files.
libisofs reads each single byte and writes it into the ISO filesystem,
regardless whether really stored or virtually generated as 0-byte from
file gaps.)

I've tried a new backup with a different set of VMs, all of these VMs are sparse, none of them are compressed.

Key to this is that I'm using the -f flag to resolve symbolic links, the tree being burned to disk is made up of various files scattered around the filesystem, and -f brings them together in one directory.

In this case we fail the dry-run, as the claim is the data is too large to fit:

[root@arnie optical]# /usr/bin/growisofs -dry-run -quiet -iso-level 3 -f -Z /dev/sr1 -r -J -A 'Example VMs' -V 'Example VMs 2024-11-25' /var/spool/backup/optical/virtual-machines

Executing 'mkisofs -quiet -iso-level 3 -f -r -J -A Example VMs -V Example VMs 2024-11-25 /var/spool/backup/optical/virtual-machines | builtin_dd of=/dev/sr1 obs=32k seek=0'

xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

:-( /dev/sr1: 24438784 blocks are free, 48920021 to be written!

[root@arnie optical]# libisofs: MISHAP : Image write cancelled

libburn : SORRY : Cannot write desired amount of 32768 bytes. write(2) returned -1. : Broken pipe

xorriso : FAILURE : libburn indicates failure with writing.

The size of the sparse data is as follows, and 40G should comfortably fit on a 50G bluray.

[root@arnie optical]# du -c -h -L virtual-machines/

30G virtual-machines/example-vms/e.example.com

11G virtual-machines/example-vms/h.example.com

40G virtual-machines/example-vms

40G virtual-machines/

40G total

The full non-sparse size of the files is 94G:

[root@arnie optical]# du --apparent-size -c -h -L virtual-machines/

54G virtual-machines/example-vms/e.example.com

41G virtual-machines/example-vms/h.example.com

94G virtual-machines/example-vms

94G virtual-machines/

94G total

I suspect that when symlinks are used, the sizes of the files are not detected properly. The not-enough-space would suggest it is taking into account the non-sparse size for calculating space, and not the sparse size.

I wonder if there is something odd on the code path when symlinks are used.

Regards,

Graham

--