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

Hi,

Ady wrote:
> my suggestion to modify the _amount_ of Cylinders was intended to 
> overcome the "by 4" (or rather, "by 2048") issue.
Now i get your intention. You want to align the
resulting ISO to 4 full cylinders in order to avoid
the need for a cylinder size divisible by 4.

This would work. But with -h 255 -s 63 it could waste
up to 32,899,072 bytes.

> Hopefully I am clarifying my suggestion in this email:
> [...] loop to step #2.
The algorithm would not have to loop for a solution
but could compute it directly:

  if (Heads * Sectors_per_track) is divisible by 4
     # Pad up to next full cylinder
     align_factor = 1
  else if (Heads * Sectors_per_track) is divisible by 2
     # Pad up to next full double cylinder 
     align_factor = 2
  else
     # Pad up to next full quatruple cylinder (nearly 32 MB)
     align_factor = 4

In isohybrid.c the resulting align_factor would be used
like this:

-    frac = isostat.st_size % cylsize;
-    padding = (frac > 0) ? cylsize - frac : 0;
+    align_cylsize = cylsize * align_factor;
+    frac = isostat.st_size % align_cylsize;
+    padding = (frac > 0) ? align_cylsize - frac : 0;

Similarly in isohybrid.in.
There is no risk that the larger padding would exceed
1024 cylinders as long as the unpadded image does not
exceed this limit.

Nice idea, i must say. Mathematically appealing.
But up to four cylinders of padding ... ?

If anybody really wants to use this, then i would
prepare a modified copy of isohybrid.c for testing.
(I'm not its author or maintainer. Somebody else would
have to bring it into Git.)


Have a nice day :)

Thomas

> Hi,
> 
> Ady wrote:
> > my suggestion to modify the _amount_ of Cylinders was intended to 
> > overcome the "by 4" (or rather, "by 2048") issue.
> 
> Now i get your intention. You want to align the
> resulting ISO to 4 full cylinders in order to avoid
> the need for a cylinder size divisible by 4.
> 
 
No :). I want to align to resulting isohybrid image size to 4 full 
cylinders *only when necessary*.

Depending on the values of Heads and Sectors_per_track (whether they 
are command-line parameters the user established, or whether they are 
the result of other command-line parameters the user might have used), 
the amount of Cylinders might not need to be a multiple of 4 (e.g. '-h 
64 -s 32').

But it also depends on the size of the ISO image (see calculations 
below).

If the first loop (in my suggestion) being used to calculate an 
attempted Cylinders (amount) is good enough, then the rest of the 
algorithm would continue. If it is not, add +1 to the first attempted 
Cylinders (amount) value and calculate the potential result. Check 
again; is it good enough? If it is, use that value of Cylinders 
(amount) and continue. If it is not, add +1 again and loop.

If the input ISO image is adequate (i.e. its size is a multiple of 2048 
bytes), then a maximum of 4 loops would be necessary. When a useful 
value of amount of Cylinders would be calculated, only _then_ move on 
with the rest of the conditions and actions. I mean that there are 
_not_ 4 attempts to actually build the isohybrid image, but only a 
maximum of 4 loops of calculations for the potential amount of 
Cylinders and the potential resulting isohybrid image size.

Now, say we have a "good" set of potential CHS values such as 
2048*255*63 so to calculate the resulting size of the isohybrid image. 
That's good for the _size_, but such amount of Cylinders is too big for 
the partition table. This condition should already be part of the 
source code (apologies, I am not a developer, so I don't have the 
knowledge to check whether this last assumption is true). Then you use 
the already-existing conditions so to use the maximum value allowed for 
the partition table (1023), as you would usually do. Just as with the 
current algorithm, the resulting size is bigger than what the partition 
table allows; nothing has changed.

The purpose of the suggested loop (instead of immediately using an 
amount of Cylinders multiple of 4) is to minimize the zero-padding.

For example, if we were to need '4*255*63*512-1' additional bytes, that 
would be less than 32MiB to be added to the input ISO image. If the 
input image size was around 1.2GiB, that's less than %2.56. Depending 
on the exact size of the ISO image, it could also be much less (the 
suggested loop would decide). For a geometry of 64/32 (for a size lower 
than 1GiB), the suggested zero-padding would result in the very minimal 
size, for any/every size of the ISO image.

Let's repeat the background calculation (please do not interpret the 
following pseudo-code as actual functions / operations in C, it is 
not):

Cylinders  trunc(roundup( ISO_size / (Heads * Sectors_per_track * 512))

where 'ISO_size' is the size, in bytes, of the input ISO image.

 (Note: roundup(n.0) = n)

So, depending on the potential set of values (ISO_size, Heads, 
Sectors_per_track) the minimum amount of Cylinders might need to be 
some "i" value, or "i+1", or "i+2" or
"i+3" (assuming ISO_size is an
adequate value, multiple of 2048 bytes). This is the loop.

Let's repeat it, for clarity:
1_ Calculate a potential Cylinders (amount) value;
2_ Calculate 'Cylinders * Heads * Sectors_per_track';
3._ Is the result of the calculation (as explained in the previous step 
#2) a multiple of '4'?
3.a_ If it is, continue (to step #4);
3.b_ If it is not, then add '+1' to the attempted Cylinders (amount) 
value and loop to step #2.
4_ Other conditions and logic already present in the isohybrid source 
code still apply (e.g. the Cylinders value could be too-high for the 
partition table, in which case the value for the partition table is 
truncated to the maximum allowed value; the input ISO image size shall 
be a multiple of 2048 bytes...).

The actual code necessary to achieve to 4 loops could be actually not a 
loop, of course. That's beyond my knowledge (had I knew how to code it, 
I would had sent a patch). Whichever the code (style, method,...), 
there are up to 4 calculations attempts.

Hopefully I am explaining it better this time.

Regards,
Ady.

Hi,
> Hopefully I am explaining it better this time.
Our ideas of implementation are supposed to yield the
same result.

As said, i am willing to implement my proposal in
a copy of isohybrid.c, if somebody wants to test it.
Advantages and disadvantages should be obvious.

Interested users please send util/isohybrid.c from
your local SYSLINUX source code installation to me.
Just to be sure that the modified copy fits into
that installation.

----------------------------------------------------------
Reasoning for my proposal (math, not computer science):
> > You want to align the
> > resulting ISO to 4 full cylinders in order to avoid
> > the need for a cylinder size divisible by 4.
 
> No :). I want to align to resulting isohybrid image size to 4 full 
> cylinders *only when necessary*.
That's what my proposed computation does.
It predicts the minimum number of cylinders which you need
as padding target in isohybrid.c (or .in).

Sorry for being sloppy with the natural language description
of the concept. Let me try it more formal:

The size of an image file which is aligned to full
cylinder size is:

  number_of_cylinders * h * s * 512

If we divide by 2048 = 2 exp 11, we can cancel
512 = 2 exp 9 and get 

  number_of_cylinders * h * s / 4

In order to cancel the remaining 4, we need two prime
factors 2 among those of number_of_cylinders, h, and s.

We find at least two 2s in h and s if and only if h * s is
divisible by 4. All is fine then. number_of_cylinders can
have any value.

We find exactly one 2 in h and s, if and only if h * s is
divisible by 2 but not by 4. So we need one factor of 2 in
number_of_cylinders. This is equivalent to padding up to
pairs of blocks. I.e. a double granularity of padding.

We find no 2 in h and s if and only if h * s is not
divisible by 2. Then we need two factors 2 in
number_of_cylinders. Thus padding up to full quatruples
of cylinders.

This does not mean that two or four cylinders get
added unconditionally. If the input has 131 cylinders
plus a few sectors, then it gets padded up to 132 cylinders.
But if it has 132 cylinders plus 4 sectors, then it must
get padded up to 136 cylinders. (Assumed -h 255 -s 63.)

This is the theoretical minimum. Math-wise.

> Now, say we have a "good" set of potential CHS values such as 
> 2048*255*63 so to calculate the resulting size of the isohybrid image. 
> That's good for the _size_, but such amount of Cylinders is too big for
> the partition table. This condition should already be part of the 
> source code
Both isohybrid programs check this already. After
padding is added to size.

The calculated padding cannot exceed cylinder 1024,
as long as the input ISO does not exceed 1024 cylinders.
That's because 1024 is a padding target in all three
granularities.


Have a nice day :)

Thomas