Le 26/10/2020 à 22:19, Michael Schmitz a écrit :
> 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 <m...@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.
Partitions smaller than 32M, are indeed formatted as FAT16 by GEMDOS.
disktype /dev/mmcblk0p4
Partition 4: 12.04 MiB (12619776 bytes, 24648 sectors from 139490)
Type "GEM" (Standard GEMDOS)
FAT16 file system (hints score 3 of 5)
Volume size 11.98 MiB (12558336 bytes, 12264 clusters of 1 KiB)
This is not a problem whatsoever for Linux: those small FAT16 partitions
are handled correctly by fsck and mount, without forcing a fat type or
option, and are working correcting in TOS too.
>> 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,
Thanks for the feedback !
>
> Michael
>
>
>>
>> Emmanuel
>>
>>
>>
>>
>
