Re: [Bug-xorriso] PMBR sizing with appended_part_as=gpt

[Thomas Schmitt]

Hi,

Paul Robins wrote:
> I wonder if perhaps we
> could adopt a syntax very similar to the existing 'interval' syntax.

The syntactical issues are not the main problem.
Up to now i do not really understand your use case.
 

> I'll experiment with modifying ISOs this weekend and get
> back to you if I have any improved proposals.

That will be interesting.


> The bug regarding no_emul_toc is one I have come across, hence the
> inclusion of it within my command. I don't know enough about CDs to know
> whether it's ultimately a good idea or not

This emulation has the purpose to preserve the session history on
overwritable "media" (among them are data files) as it would be preserved
on a sequential multi-session medium (CD-R[W], DVD-R[W], DV+R, BD-R).
Mostly interesting for incremental backups.

At the cost of 32 blocks dedicated to a frequently updated superblock
it enables xorriso to tell start block, size and label of each session:

$ xorriso -indev /dev/sr4 -toc
..
Media current: BD-RE
...
Media blocks : 8567520 readable , 3520800 writable , 12088320 overall
TOC layout   : Idx ,  sbsector ,       Size , Volume Id
ISO session  :   1 ,        32 ,   2128283s , HOME_2018_08_20_203037
ISO session  :   2 ,   2128320 ,     78113s , HOME_2018_08_21_152650
ISO session  :   3 ,   2206464 ,     77627s , HOME_2018_08_22_154401
...
ISO session  : 143 ,   8465440 ,     33022s , HOME_2019_01_09_150918
ISO session  : 144 ,   8498464 ,     35299s , HOME_2019_01_10_152803
ISO session  : 145 ,   8533792 ,     33708s , HOME_2019_01_11_162901
Media summary: 145 sessions, 8565133 data blocks, 16.3g data, 6877m free

That way i can access the backup state of each day between 20 Aug 2018 and
today. (Roughly more 100 days are expected to fit on that medium.)

The superblock at block 0 points to the same root directory as the
superblock at block 8533792.
("Superblock" means ISO 9660 System Area and ISO 9660 Volume Descriptors.
 The System Area contains the partition tables.)

The bug was that the GPT was prepared with the size of the filesystem
as pointed to by the superblock at block 0. Later a GPT was prepared
with the filesystem size as in the superblock at block 32. That size is
32 blocks less. But the last partition, which claims the elsewise
unclaimed block range up to the end of the filesystem, was alreadyi
repared for the larger size. Bang. 32 blocks too large.

It seemed too risky to prevent the whole GPT production for session 1,
although that GPT will normally never be recognized by any system.
Instead i mark the filler partition request objects and remove them
as soon as the superblock for block 0 is produced.
New fillers = correct sizes.


Have a nice day :)

Thomas