[Bug 243178] newfs_msdos: wrong FAT type determination

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243178

Stefan Eßer <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open
                 CC|                            |[email protected]

--- Comment #8 from Stefan Eßer <[email protected]> ---
(In reply to Damjan Jovanovic from comment #7)
I have fixed issues with the calculation of msdosfs before. I found the
complexity of this code annying and the cryptic variable names do not aid the
understanding of the code (which took me quite some time, when I fixed the
start of the data region to be aligned with common page sizes to allow use of
64 KB clusters without changing the maximum file system buffer size in the
kernel).

If there is interest in a replacement of the complete logic that performs these
calculations by one that is more structured and easier to understand, then I
offer to first create test cases that cover all edge cases and then to refactor
the code to use a morre rational function that calculates the parameters,
instead of having all these calculations inline in the mkfs_msdos() function.

But I'm only going to spend that effort on a rewrite of that logic if there is
interest in a cleaned-up version of this code and I can assume it to be
reviewed and approved.


Regarding the suggested changes to either the reduce the number of clusters
(and have unused sectors at the end) or the smaller cluster size:

If the cluster size is cut in half, the number of entries is doubled, and since
we are near the upper limit of clusters supported by FAT16 at > 65500 clusters,
this would add about 384 KB per FAT or 768 KB with 2 FATs (for doubling the
number of FAT entries and going from 16 to 32 bits per cluster number in the
FAT).

The larger FAT region (due to a smaller cluster size) is easily compensated for
by less unused space in the last cluster of each file. Therefore, it appears to
be the better solution than a reduction of the number of clusters below the
limit for FAT16.

-- 
You are receiving this mail because:
You are the assignee for the bug.