Syslinux - Feb 2015 - isohybrid and ISO images whose size is not a multiple of 2048 bytes vs. VirtualBox

Hi,
> What about '-h 255 -s 63 , ISO size 1085736960' ?
-h 255 -s 63 , ISO size 1085736960 :
  align_factor= 4 , padding= 0 , image size= 132.000000 cylinders

-----------------------------------------------------------------
Code of isohybrid_test_mockup.c :
-----------------------------------------------------------------

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
 int cylsize = 0, frac = 0, align_factor, align_cylsize;
 int padding;
 unsigned long img_size;
 int head, sector;

 sscanf(argv[1], "%d", &head);
 sscanf(argv[2], "%d", &sector);
 sscanf(argv[3], "%lu", &img_size);

 /* Begin of isohybrid.c code */

    /* Making sure that the resulting image size is divisible by 2048.
       (Can waste nearly 32 MB. Should be done on user request only.)
    */
    if ((head * sector) % 4 == 0)
        align_factor = 1;
    else if ((head * sector) % 2 == 0)
        align_factor = 2;
    else
        align_factor = 4;

    cylsize = head * sector * 512;
    align_cylsize = cylsize * align_factor;
    frac = img_size % align_cylsize;
    padding = (frac > 0) ? align_cylsize - frac : 0;

 /* End of isohybrid.c code */

 printf("-h %d -s %d , ISO size %lu :\n", head, sector, img_size);
 printf("  align_factor= %d , padding= %d , image size= %f
cylinders\n",
        align_factor, padding,
        (double) (img_size + padding) / (double) cylsize);

 exit(0);
}

-----------------------------------------------------------------
End of code
-----------------------------------------------------------------

Compile by

  cc -g -Wall -o isohybrid_test_mockup isohybrid_test_mockup.c

Run as e.g.

  ./isohybrid_test_mockup 255 63 1085736960

> > I expect the average waste to be a bit less than 16 MB.
> Yes, but slightly misleading. For example, the "16MB average" is 
> relevant for 255/63.
We advise two geometries: -h 63 -s 32 and -h 255 -s 63.
isohybrid behavior with the first one will not be changed.
With the second one it would waste 16 MB in average.

> Some user reading the code might not know the whole reasoning for:
This is not yet a proposal for changing isohybrid.c.
It is for testing the consequences of the idea on
real ISOs. If anybody is interested to do so ...

> Note that I also removed the second phrase, "Should be done on user 
> request only", as I disagree.
Whoever decides about committing a final patch will also
decide whether this behavior should be hardcoded, or be
default, or need to be enabled explicitely by the user.

I'd vote for the latter.

> I would not expect distro maintainers to edit 
> isohybrid.c so to make use of the patch;
Of course a final patch would offer an option to enable
the feature. Something like --big-align alias -B.


Have a nice day :)

Thomas

Just a small correction:

Thomas Schmitt via Syslinux <syslinux at zytor.com> wrote:
> > > I expect the average waste to be a bit less than 16 MB.
> > Yes, but slightly misleading. For example, the "16MB
average" is
> > relevant for 255/63.
> 
> We advise two geometries: -h 63 -s 32 and -h 255 -s 63.
> isohybrid behavior with the first one will not be changed.
> With the second one it would waste 16 MB in average.
The average waste in the second case is just under 12 MiB.  If
you assume random distribution of ISO sizes, you have to pad by
0, 1, 2, or 3 cylinders with equal probability.  That averages
to 1.5 cylinders, or 12,337,920 bytes, which is just under 12 MiB.

Hi,

Rich Mahn:
> The average waste in the second case is just under 12 MiB.  If
> you assume random distribution of ISO sizes, you have to pad by
> 0, 1, 2, or 3 cylinders with equal probability.  That averages
> to 1.5 cylinders, or 12,337,920 bytes, which is just under 12 MiB.
That's because align_factor 1, the current method with
255x63, already produces about 4 MB of average waste.

You are right that the additional average waste by
align_factor 4 in the proposed method is only 12 MB
and additional worst case waste is only 24 MB.


Have a nice day :)

Thomas

> 
> Just a small correction:
> 
> Thomas Schmitt via Syslinux <syslinux at zytor.com> wrote:
> 
> > > > I expect the average waste to be a bit less than 16 MB.
> > > Yes, but slightly misleading. For example, the "16MB
average" is
> > > relevant for 255/63.
> > 
> > We advise two geometries: -h 63 -s 32 and -h 255 -s 63.
> > isohybrid behavior with the first one will not be changed.
> > With the second one it would waste 16 MB in average.
 
The 255/63 geometry is indeed very relevant. I was just pointing out 
that the "average of almost 16MB of waste" is slightly misleading 
because "average" would suggest to users that it accounts for every 
potential case (maybe even including other geometries). This is not the 
case; that average is just for 255/63 (and ISO size > 1GiB).
 
> 
> The average waste in the second case is just under 12 MiB.  If
> you assume random distribution of ISO sizes, you have to pad by
> 0, 1, 2, or 3 cylinders with equal probability.  That averages
> to 1.5 cylinders, or 12,337,920 bytes, which is just under 12 MiB.
 
The potential padding (waste) for a geometry of 255/63 (and ISO size 
bigger than 1 1GiB) goes from 0 bytes up to '4*255*63*512-2048' bytes. 
Whether we classify / divide the padding area in cylinders or using any 
other measurement unit, it doesn't change the range of bytes.

In any case, isohybrid already has some zero-padding. We are not adding 
32MB (max), nor 16MiB in average to the current (as of 6.03) already 
present waste. We _might_ be adding, in total, *up to* 32MB in certain 
cases, where the input ISO size is at least 1GiB.

I don't like waste. I don't like bloat. I don't like
"all-in-one". But,
if I were a distro maintainer releasing 1GiB+ ISO images, I'd rather 
have it "simply working" (for dummies), instead of having a
"known
issues: it might not work as virtual optical media" messages.

There is a cost to isohybrid (in comparison to common ISO images). 
There is a cost already (as of 6.03). There is a potential additional 
(differential) cost if this patch is used by default. The potential 
differential cost is around %1 (in order of magnitude). The total cost 
of isohybrid (not just because of this patch, but about any isohybrid) 
_might_ be around %2 in some cases.

I would tend to think that most distro maintainers would rather pay the 
cost, for common users and beta testers sake. That's just my _guess_ 
and there is no way to prove it, nor the opposite.

Having a test from TAILS would be nice and appreciated.

Regards,
Ady.
 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>