Hi Emmanuel, On 27/10/20 6:13 AM, Emmanuel Kasper wrote:
Le 26/10/2020 à 11:44, Geert Uytterhoeven a écrit :Hi Emmanuel, CC Michael On Mon, Oct 26, 2020 at 11:28 AM Emmanuel Kasper <manu@debian.org> wrote:Note that we still have a few out-of-tree kernel patches for Atari FAT support as well, cfr. the top 3 commits of https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=m68k-queue Needs some love from a knowledgeable person to send this upstream... Gr{oetje,eeting}s,Hi Geert ! I had a look at the patches as I was dabbling in GEMDOS FAT handling these days, and I have to say I don't understand the purpose of the commit you mentioned: fat: Atari FAT updates Add support for the Atari-variant of the FAT filesystem https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/commit/?h=m68k-queue&id=501bd95410f8347ed80bff873498db7a1b044457 to the best of my knowledge, Linux was always able to mount Atari FAT partitions, as long as the logical sector size of the FAT was up to 4096 bytes, this limit itself coming from https://github.com/gregkh/linux/blame/071a0578b0ce0b0e543d1e38ee6926b9cc21c198/fs/fat/inode.c#L1508 what problem is being fixed, or new feature added with the patch ? or am I missing something ?TBH, I don't know. This patch came from the old Linux/m68k CVS.
I can't recall why I had decided to port it from 2.4 either, but there would have been a real problem to fix at that time (such as failing to mount the TOS boot partition from Linux). I would probably had noticed about the time compressed kernels got too big to be copied to the Falcon using floppies...
That problem now appears to have gone away. I had to replace the IDE disk in my Falcon a few times, and I might have finally managed to set compatible or sane FAT options on the last attempt ...
Looking at the patch, the only reason I can see is that AFAIK(?), GEMDOS always uses a 16 bit FAT, even though the partition size may be small enough to use a 12 bit FAT. The biggest such partition that would have been possible to mount for Linux would be about 32 MB (entirely reasonable size, many years ago).
If anyone feels it can be dropped, I can do so. If anyone feels it is needed, please submit it upstream.I had a second look at the code and the patch seems to try to improve the detection of FAT12 filesystems. However those are properly detected by the kernel anyway, (5.8.0 here) sudo mkfs.fat -F 12 /dev/mmcblk0p4 sudo disktype /dev/mmcblk0p4 --- /dev/mmcblk0p4 Block device, size 12 MiB (12582912 bytes) FAT12 file system (hints score 4 of 5) Volume size 11.96 MiB (12546048 bytes, 3063 clusters of 4 KiB) sudo mount /dev/mmcblk0p4 /mnt -> works The same partition formatted with GEMDOS is also properly correctly detected by the kernel and mounted.
For the current GEMDOS partition on my system (128 MB), the 'atari' option indeed makes no difference. I suspect that a FAT16 file system small enough to be detected as FAT12 would cause problems though.
Your 12 MB GEMDOS partition does work OK in TOS? That would suggest my assumption about 16 bit FAT is wrong, and the patches are indeed no longer required.
A FAT 12 MS DOS floppy is also correctly mounted via mount without specifying the fat type. IMHO the patch is not needed anymore, or is covering a use case I don't see.
With what you've reported, I can't see what use case this patch would have enabled either. For all I care, we should drop the three FAT related commits at the head of m68k-queue.
Cheers, Michael
Emmanuel