Re: [MiNT] FreeMiNT and cluster size

[Paul Wratt <paul.wratt@gmail.com>]

On Tue, Aug 23, 2011 at 4:28 PM, Roger Burrows <rfburrows@ymail.com> wrote:
> Hello Vincent,
> On 22 Aug 2011 at 15:59, Vincent Rivière wrote:
>>
>> I have a single FAT16 partition (sizes in bytes):
>> - sector size: 512
>> - cluster size: 16384 (32 sectors)
>>

>> It works fine with EmuTOS alone, but I can't use it with FreeMiNT's
>> NEWFATFS.
>>
from mkfatfs:
-s <num>      Sectors per cluster (2, 4, 8, 16, 32, 64, or 128)

>> EmuTOS provides an AHDI cookie to a PUN_INFO structure:
>> http://toshyp.atari.org/en/00300b.html#PUN_INFO
>>
>> The field P_max_sector is defined as "the largest occurring block size
>> for BIOS sectors".
>> On my setup EmuTOS returns 512 in this field, and I believe this is correct.
>>
512 byte sectors is the norm for standard FAT formatted at BIOS level.
Only NT 3/4 can read Fat volume with 1024 byte sectors

for that define to be true it should say:
  "the largest size for a BIOS sector". or maybe
  "the largest physical block size for BIOS sectors"

Because it says "largest occurring block size" and "BIOS sectors" (not
sector) this implies Logical Sectors

that cache setting in block_IO.c is exactly that a cache. notice it
also has a block counter and a chunk size. but max_size is not the
size of the cache and MIN_BLOCK is an arbitrary value

so either:
1)" if (xbpb->clsizb > max)" is the wrong evaluation (depends if it
gets used to read "clsizb" bytes)
2) "cache.max_size" should next evaluate XHDI (XH_DL_CLSIZB) after
interrogating PUN_INFO
3) "MIN_BLOCK" should be raised (may hit same problem in future)


> I looked in pun.h in FreeMiNT, and the comment is "Max logical sec size".
>
>> Then in FreeMiNT's sys/block_IO.c, function init_block_IO(), we can see:
>>      if (pun)
>>          cache.max_size = pun->max_sect_siz * 2L;
>>
>> So in my case I will get cache.max_size == 1024.
>>
>> Just after that, we can see:
>>      cache.max_size = MAX (cache.max_size, MIN_BLOCK);
>> where MIN_BLOCK == 8192
>>
>> Finally I have cache.max_size == 8192.
>>
>> But later, in sys/fatfs.c, function val_bpb(), there is:
>> // max = cache.max_size (8192)
>> // xbpb->clsizb (16384)
>>      if (xbpb->clsizb > max)
>>      {
>>          FAT_ALERT (("FATFS [%c]: unitsize (%li) too small (clsizb =
>> %li)!", 'A'+drv, max, xbpb->clsizb));
>>          FAT_ALERT (("FATFS [%c]: medium access denied", 'A'+drv));
>>
>> Fatally, this fails for me with "FATFS [C]: unitsize (8192) too small
>> (clsizb = 16384)!" and I can't use my partition.
>>
>> The cache.max_size setting seems good to me, with a sensible minimum value.
>> But the fatfs test comparing a cluster size with a maximum sector size
>> looks totally bogus. Am I wrong ?
>>
> With the latter test, it looks like NEWFATFS is saying that a cluster must be
> containable in a unit, which I think makes sense.
>
> In init_block_IO(), I think it's trying to convert the logical sector size
> returned by get_pun() into a cluster size, by multiplying by two.  And then
> with max() it's allowing for an 8K cluster size at least.
>
nope, its physical (not logical), so setting the cache with x2 would
only be a "saftey margin". There is not enough info in PUN_INFO to
calculate a cluster size.

The problem with the 8K min is that it does not get enlarged anywhere,
so it becomes a max too.. BTW in my previous post I stated "all of
which say 8Kb max, with logical being <=8Kb" which is actually 2 fact
combined (I have been reading lots lately).
1) physical blocksize must be smaller or equal to logical blocksize
2) Frank wrote in multiple docs "blocksize 8kb"

> Since AFAIK, the only valid info provided by EmuTOS in the PUN_INFO structure
> is max_sec_size, and that is only there to stop FreeMiNT complaining, perhaps
> the easiest fix would be to change the value from EmuTOS to clsizb/2.
>
I think that will cause problems because it is a Physical BIOS Sector
Size, which is probably relied upon by some apps (in PUN_INFO)

In fact the only "real" info in the PUN_INFO is the sector size

> But I'm sure someone who actually knows what he's talking about will provide
> the correct answer :-).
>
> Roger Burrows
>
It was a good start.. at least I got a chance to look at the code
because of what you wrote.. cheers for that :)

It might be ok to increase the MIN_BLOCK, but it may affect some other
parts of the system (ext2). The highest cluster size FAT16 can go to
is 32K, but that does not cover most modern drives either..
..apparently cache is modified for ext2 depending on a cookie

I wounder if Vincents original failure would occur if it was an ext2
format partition (or other)

I think adding an XHDI evaluation after PUN_INFO interrogation will
get the best results

Paul