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:30:41 -0400

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]