libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] Rock Ridge deep directory support


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] Rock Ridge deep directory support
Date: Tue, 16 Jun 2020 12:31:43 -0400

But,Thomas, if you want to redo so it is smaller that's okay too.

On Tue, Jun 16, 2020 at 12:30 PM Rocky Bernstein <rocky@gnu.org> wrote:

> Ok. I let's just go with the existing image.
>
> On Tue, Jun 16, 2020 at 12:04 PM Pete Batard <pbatard@gmail.com> wrote:
>
>> On 2020.06.16 15:48, Thomas Schmitt wrote:
>> > But if it is for size, then the existing
>> >    test/data/deep-directory.iso
>> > is too large by the traditional padding of 150 * 2048 bytes (which is
>> > needed only if the ISO gets onto a CD by write type TAO from which it
>> > shall be read by the Linux kernel's block device driver).
>> >
>> > So Pete could re-create it by mkisofs using option -no-pad.
>> > It would then shrink from 397,312 bytes to 90,112.
>> >
>> > Alternatively one could simply compress the ISO in git and tarball and
>> > let the test program decompress it:
>> >
>> >    $ gzip -9 <test/data/deep-directory.iso | wc -c
>> >    2420
>>
>> Three things about this:
>>
>> 1. git does compress content behind the scenes pretty effectively, so
>> the only size issue here is with users having to ensure that they have a
>> "whooping" 300 KB extra free to host their repo... which, in 2020, I
>> hope is not something we feel we have to lose sleep over.
>>
>> 2. I've been using Folder2Iso to create that image (because it was the
>> most convenient), which calls mkisofs behind the scenes but does not
>> provide options to alter settings.
>>
>> 3. I am estimating that the time I would spend recreating the ISO to
>> save those 300 KB which aren't actually going to cost us repository
>> space is simply not worth the effort at this stage. There's just nothing
>> to be gained from saving a couple hundred KB (again, not in bandwidth,
>> thanks to git compression) for people who clone our repo. As such I am
>> not planning to update the proposed test ISO, as I'd rather use the time
>> I'm going to save not doing that on other things (such as ensuring one
>> last time that what I am going to merge is not going to create issues).
>>
>> I hope that it's okay. And yes, I do understand that, ideally, we'd like
>> to provide the smallest test ISOs or be as academical as we possibly
>> can, but I'd rather invest time, which is always in short supply, on
>> elements that will actually improve people's lives, and this just isn't
>> one of them...
>>
>> Regards,
>>
>> /Pete
>>
>>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]