Re: [Libcdio-devel] Can we merge branch "joliet_multi_extent" ?

[Rocky Bernstein]

On Mon, Mar 27, 2023 at 8:49 AM Rocky Bernstein <rocky@gnu.org> wrote:

>
>
> On Mon, Mar 27, 2023 at 7:23 AM Thomas Schmitt <scdbackup@gmx.net> wrote:
>
>> Hi,
>>
>> Rocky Bernstein wrote:
>> > Here is a suggestion - in that branch add the new ISO image that you
>> created.
>> > And then add a new test for this feature.
>>
>> It seems easiest to extend test "check_multiextent.sh".
>> (The main obstacle which gave me riddles was missing TZ=CUT when i
>> created multiextent_joliet.right.)
>>
>> The Joliet test ISO is significantly smaller than the old one for
>> Rock Ridge:
>>   -rw-r--r-- 1 . . 524288 Jun 17  2020 test/data/multi_extent_8k.iso
>>   -rw-r--r-- 1 . . 122880 Mar 27 10:56
>> test/data/multi_extent_8k_joliet.iso
>> But strangely du says that it uses more disk space on ext4:
>>   100     test/data/multi_extent_8k.iso
>>   120     test/data/multi_extent_8k_joliet.iso
>> I guess this is the effect of sparse file storing. But i am not aware that
>> i ever gave multi_extent_8k.iso a special treatment back in 2018.
>> Is git known to work with sparse file generating seeks when checking out
>> files ?
>>
>>
>> The old multi_extent_8k.iso is nominally so much larger, because i
>> obviously did not apply space saving options when creating it:
>> 64+ KiB are used for multi-session TOC emulation. 300 KiB are trailing
>> padding against the Linux TAO CD bug.
>>
>> I could create it freshly with 122880 bytes. Shall i do ?
>>
>
> Sure, try that or try creating a different image. BTW, when creating ISO
> images please try to use the smallest amount of data that will do the job.
>

Actually, a new image is better. We want to be able to handle historical
images that were not created optimally.


>
>
>>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>>