search for: align_factor

...isohybrid.c 2015-02-20 10:43:49.000000000 +0100 +++ isohybrid_test.c 2015-02-20 11:01:33.000000000 +0100 @@ -947,7 +947,7 @@ main(int argc, char *argv[]) int i = 0; FILE *fp = NULL; uint8_t *buf = NULL, *bufz = NULL; - int cylsize = 0, frac = 0; + int cylsize = 0, frac = 0, align_factor, align_cylsize; size_t orig_gpt_size, free_space, gpt_size; struct iso_primary_descriptor descriptor; @@ -1058,9 +1058,20 @@ main(int argc, char *argv[]) isosize = lendian_int(descriptor.size) * lendian_short(descriptor.block_size); free_space = isostat.st_size - isosize; +...

> > Same result as yours. > > > Have a nice day :) > > Thomas > I was under the impression (apparently the wrong one) that your pseudo-code was adding 4 cylinders to the first example, from 132 to 136, which would be non-optimal. Since I am not a developer, I believe you when you say that such jump won't happen :). Perhaps the code will be more clear to me

...Ady wrote: > ISO size: 1'085'736'960 bytes ( > 1GiB) This are exactly 132 cylinders of 255x63. 132 is divisible by 4. So there is no padding needed. > Cylinders (1st attempt)=132 > [...] > 2120580 / 4 = 530145, so the answer is "yes". My calculation gets align_factor = 4. So isohybrid would pad up to quadruple cylinders. Well, 132 is already such a quadruple. > When comparing your code with my suggested calculation, I see that your > conditionals do not account for the ISO image size, but only for > "Heads" and "Sectors_per_track&quo...

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 **ar...

> > I wrapped the essential code into a standalone program for > playing with a few numbers: What about '-h 255 -s 63 , ISO size 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. Some user reading the code might not know the whole reasoning for: >

...". 3.a_ If it is, continue (to step #4). Since the answer was "yes", we end the loop and we have found the minimal Cylinders amount that achieves our conditions. Now, if I take your code: 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 For the example I am presenting here, "Heads*Sectors_per_track" is 255*...

...ld 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 = is...

> Hi, > > Ady wrote: > > I am not so sure that using a different pair of '-h' and '-s' values > > would be better than using 255/63. > > But 255 * 63 is not divisible by 4 and thus can cause > trouble with virtual DVD-ROM. And my suggestion to modify the _amount_ of Cylinders was intended to overcome the "by 4" (or rather, "by

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

Hi, Ady wrote: > I am not so sure that using a different pair of '-h' and '-s' values > would be better than using 255/63. But 255 * 63 is not divisible by 4 and thus can cause trouble with virtual DVD-ROM. > Most BIOS and most partition editors would assume this geometry. I cannot tell for BIOSes, but partition editors have options to set heads-per-cyl and

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