[syslinux] [PATCH 1/5] fat: fix minfatsize for large FAT32

[Ady]

> On 2016.02.26 15:32, Ady via Syslinux wrote:
> > Regarding the "+1", when talking about the math (not the computer code
> > to achieve a result as accurate as it can be)
> 
> Well, sorry, but I will not dissociate the context of application from 
> the formula itself. I thought this was implied into what I wrote, which 
> was in the context of fixing a computation algorithm bug. The sole 
> interest I (and I posit others should) have in the formula is how it 
> applies to computer code, as we are not trying to write a mathematical 
> proof in the absolute here, but instead code that meets the requirements 
> of using all potentially addressable sectors. *This* is the only context 
> of correctness that should matter. Anything else, as interesting as it 
> may be, is sidetracking and not something I personally want to 
> participate in.
 
 
I am actually agreeing with you. My point was that _I_ cannot make 
comments on correctness when we get into the code. I am not proposing a 
discussion about math; but rather pointing out my own limitations to be 
able to answer to your question / suggestion (for someone else to 
suggest some algorithm to solve the issue in the computer code). In 
fact, I said it before; from the point of view of the computer code, 
all these minor variations might be OK anyway (or, let's call them 
"OK-enough" for their purposes?).

You might have noticed that also the sources you have linked to in 
prior emails include some kind of phrase referring to not being 100% 
accurate or complete (e.g. not getting into the rounding, or into the 
problems with the "1.5" for FAT12 instead of the simpler "2" for FAT16 
and "4" for FAT32, or the simplified, slightly inaccurate calculations 
used by other parties...).

> 
> > we should
> > at least test the values that are around or close to the limits between
> > FAT12/16/32.
> 
> There I'm going to reduce the context even further: In the context where 
> this algorithm is applied in Rufus, we don't care about non FAT32 
> computations, or ones performed for disks that are less than 32 GB in 
> size (for which the sectors per cluster will never be 1 even with 4K 
> sectors as our minimal cluster size is 8K as soon as we reach 31GB).
> 
> That's not to say that I wouldn't pick on improvements to the new 
> computation algorithm [1] when low values are used, if such improvements 
> are actually needed, and if *somebody else* kindly wants to figure them 
> out, as there is always the possibility that other developers might 
> re-use the code from Rufus and try to apply it to <31GB drives. But, in 
> the context I am concerned with, I don't see any potential issue on the 
> horizon from not performing that homework. So, there again, I will 
> simply say thanks for bringing attention to these matters, while at the 
> same time mention that I'm simply gonna pass on those, since they appear 
> irrelevant with regards to the context that matters in my application...
> 
> Regards,
> 
> /Pete
> 
> [1] 
> https://github.com/pbatard/rufus/blob/b9caf8b6058de12bf028f907471561a6aa50f7e9/src/format.c#L349-L366
 
The suggestion to test with smaller values is a practical way to test 
the whole matter. Equivalent conclusions could be obtained with bigger 
values, but the smaller values are easier to manage without an actual 
binary program (which I am not capable of writing nor executing, if it 
were to exist). So, in this context, it doesn't really matter that some 
values are less frequent in real life, or that RUFUS is not involved 
with such small values, but rather the importance resides in being able 
to arrive to conclusions regarding the minfatsize value. The use of 
small values for the tests is not an impediment to extend the same 
conclusions for other values.

Additionally, the potential conflict between FAT types around the 
limits in the valid values of amount of Clusters makes it especially 
relevant for testing. Whichever problem we might find while testing 
"big" values, they would be even worse when around the edge cases 
between FAT types.


Now, since the patches in this set seem to be independent from each 
other (based on their respective descriptions), I guess that the other 
patches can be evaluated and eventually included in the official 
Syslinux code. That's up to the dev. team.

As for the minfatsize patch, perhaps we might have some additional 
input in the future (?). In the meantime, I would assume that the idea 
of improving the 'syslinux -f' command should actually move forward. 
That's also for all of you, developers ;).

Regards,
Ady.