Considering it is possible to mount such a partition as root with sudo
mount /dev/mmcblk0p1 /mnt what would need be in udev to recognize the filesystem ?
Am 08.09.20 um 11:02 schrieb Emmanuel Kasper:
Considering it is possible to mount such a partition as root with sudo mount /dev/mmcblk0p1 /mnt what would need be in udev to recognize the filesystem ?
udev is about devices, not filesystems. Just use above mount command to
mount it (given the kernel has support for it, either built in or as a module). If you want udev to create a more convenient name for
/dev/mmcblk0, you need to write a rule for it.
Now I had a quicklook at libblkid, and it should be able at first view
to cope with sector size up to 4096 bytes, so I am a bit puzzled here. https://github.com/karelzak/util-linux/blob/master/libblkid/src/superblocks/vfat.c#L218
On Tue, Sep 08, 2020 at 05:07:50PM +0200, Dirk Heinrichs wrote:
Am 08.09.20 um 11:02 schrieb Emmanuel Kasper:
Considering it is possible to mount such a partition as root with sudo
mount /dev/mmcblk0p1 /mnt what would need be in udev to recognize the
filesystem ?
udev is about devices, not filesystems. Just use above mount command to
mount it (given the kernel has support for it, either built in or as a
module). If you want udev to create a more convenient name for
/dev/mmcblk0, you need to write a rule for it.
That almost sounds like libblkid isn't recognizing the FS. Can you try running blkid on the device? If it can't detect the FS type, that might
be a place where there is an issue. The libblkid code is not based on
the drivers in the kernel, but is still essential for a portion of the auto-detection of file systems in user-space.
Hi Emmanuel!
On 9/9/20 9:25 AM, Emmanuel Kasper wrote:
Now I had a quicklook at libblkid, and it should be able at first view
to cope with sector size up to 4096 bytes, so I am a bit puzzled here.
https://github.com/karelzak/util-linux/blob/master/libblkid/src/superblocks/vfat.c#L218
It might be worth asking on the util-linux upstream mailing list as the maintainers
are usually very responsive and helpful.
Le 08/09/2020 à 23:25, Brad Boyer a écrit :
On Tue, Sep 08, 2020 at 05:07:50PM +0200, Dirk Heinrichs wrote:
Am 08.09.20 um 11:02 schrieb Emmanuel Kasper:
Considering it is possible to mount such a partition as root with sudo >>> mount /dev/mmcblk0p1 /mnt what would need be in udev to recognize the
filesystem ?
udev is about devices, not filesystems. Just use above mount command to
mount it (given the kernel has support for it, either built in or as a
module). If you want udev to create a more convenient name for
/dev/mmcblk0, you need to write a rule for it.
That almost sounds like libblkid isn't recognizing the FS. Can you try running blkid on the device? If it can't detect the FS type, that might
be a place where there is an issue. The libblkid code is not based on
the drivers in the kernel, but is still essential for a portion of the auto-detection of file systems in user-space.
Indeed blkid does not recognize the FS type, thanks for the hint !
sudo blkid -p /dev/mmcblk0p1
/dev/mmcblk0p1: PART_ENTRY_SCHEME="atari" PART_ENTRY_TYPE="BGM" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2" PART_ENTRY_SIZE="131072" PART_ENTRY_DISK="179:256"
I suppose this is because the Atari GEMDOS FAT16 partitions have a
variable sector size wich is larger that 512 bytes for partitions >
16MB, whereas MSDOS FAT16 always uses a 512 bytes sectorsize .
This variable sector size may be what causes the trouble here - see theThat almost sounds like libblkid isn't recognizing the FS. Can you try
running blkid on the device? If it can't detect the FS type, that might
be a place where there is an issue. The libblkid code is not based on
the drivers in the kernel, but is still essential for a portion of the
auto-detection of file systems in user-space.
Hi Brad
Indeed blkid does not recognize the FS type, thanks for the hint !
sudo blkid -p /dev/mmcblk0p1
/dev/mmcblk0p1: PART_ENTRY_SCHEME="atari" PART_ENTRY_TYPE="BGM" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2" PART_ENTRY_SIZE="131072" PART_ENTRY_DISK="179:256"
I suppose this is because the Atari GEMDOS FAT16 partitions have a
variable sector size wich is larger that 512 bytes for partitions >
16MB, whereas MSDOS FAT16 always uses a 512 bytes sectorsize .
The disktype tool, provided in the archive, gave me the hint about the
sector size difference:
http://disktype.sourceforge.net/doc/ch03s03.html
and this technical guide, which has all the FAT subtilities explained: http://info-coach.fr/atari/documents/_mydoc/Atari_HD_File_Sytem_Reference_Guide.pdf
sudo disktype /dev/mmcblk0p1
--- /dev/mmcblk0p1
Block device, size 64 MiB (67108864 bytes)
FAT16 file system (hints score 3 of 5, ATARI ST bootable)
Unusual sector size 4096 bytes
Volume size 63.95 MiB (67051520 bytes, 8185 clusters of 8 KiB)
Hi Emmanuel,
On 9/09/20 7:25 PM, Emmanuel Kasper wrote:
This variable sector size may be what causes the trouble here - see the commit log of the commit at the head of Geert's m68k-queue.
That almost sounds like libblkid isn't recognizing the FS. Can you try
running blkid on the device? If it can't detect the FS type, that might
be a place where there is an issue. The libblkid code is not based on
the drivers in the kernel, but is still essential for a portion of the
auto-detection of file systems in user-space.
Hi Brad
Indeed blkid does not recognize the FS type, thanks for the hint !
sudo blkid -p /dev/mmcblk0p1
/dev/mmcblk0p1: PART_ENTRY_SCHEME="atari" PART_ENTRY_TYPE="BGM"
PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2" PART_ENTRY_SIZE="131072"
PART_ENTRY_DISK="179:256"
I suppose this is because the Atari GEMDOS FAT16 partitions have a
variable sector size wich is larger that 512 bytes for partitions >
16MB, whereas MSDOS FAT16 always uses a 512 bytes sectorsize .
The disktype tool, provided in the archive, gave me the hint about the
sector size difference:
http://disktype.sourceforge.net/doc/ch03s03.html
and this technical guide, which has all the FAT subtilities explained:
http://info-coach.fr/atari/documents/_mydoc/Atari_HD_File_Sytem_Reference_Guide.pdf
sudo disktype /dev/mmcblk0p1
--- /dev/mmcblk0p1
Block device, size 64 MiB (67108864 bytes)
FAT16 file system (hints score 3 of 5, ATARI ST bootable)
Unusual sector size 4096 bytes
Volume size 63.95 MiB (67051520 bytes, 8185 clusters of 8 KiB)
According to my recollection, the FAT logical sector size is limited to
4k by the physical page size (m68k MMU limitation), resulting in a
partition size limit of 256 MB (>128 MB must use 4k logical sectors).
Your partition shows this sector size already below that limit, which is
odd. 8k cluster size with 2 logical sectors of 4k per cluster does
correspond to a TOS partition, though.
Have you tried to manually mount the partition?
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 ?
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 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.
If anyone feels it can be dropped, I can do so.
If anyone feels it is needed, please submit it upstream.
works
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
TBH, I don't know. This patch came from the old Linux/m68k CVS.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 ?
If anyone feels it can be dropped, I can do so.I had a second look at the code and the patch seems to try to improve
If anyone feels it is needed, please submit it upstream.
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.
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.
Emmanuel
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:
TBH, I don't know. This patch came from the old Linux/m68k CVS.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 ?
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.I had a second look at the code and the patch seems to try to improve
If anyone feels it is needed, please submit it upstream.
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
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.
Hi,
On 10/27/20 12:19 PM, Emmanuel Kasper wrote:
Partitions smaller than 32M, are indeed formatted as FAT16 by GEMDOS.
Formatted by GEMDOS?
Hard disk support in Atari TOS requires separate
hard disk drivers. Those have utilities for
hard disk formatting, TOS supports only formatting
of floppies.
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.
There are many historical hard disk drivers and
formatting utilities for Atari. I think the only
still maintained (commercial) one is HD Driver
(hddrutil.app):
https://www.hddriver.net/en/
But in theory users might still have hard disks
formatted by the older hard disk programs like
Cécile (cc_tools.app), ICDPro (icdfmt.prg), CBHD
(cbhdconf.app) or Atari's AHDI (hdx.prg).
(Older versions of them may also have formatted
hard disk slightly differently.)
Which of the Atari hard disk formatting utilities
you tried?
Do we still care about hard disks that have been formatted with native
Atari SW, when user can
mount them in a PC emulator like Hatari, copy
files to safety and re-format the disk?
Ha, I did not know that the FAT16 support was coming from the hard disk driver ! I used AHDI 5.0 in my test.
According to the Table in 4.9.1, in http://info-coach.fr/atari/documents/_mydoc/Atari_HD_File_Sytem_Reference_Guide_v1.1b.pdf
all other hard disk drivers can also access FAT16 partitions < 32 MB.
I don't know if the other drivers would *create* FAT12 partitions in any case, but since the above guide never talks about FAT12, I would be
suprised if they did.
Do we still care about hard disks that have been formatted with native
Atari SW, when user can
mount them in a PC emulator like Hatari, copy
files to safety and re-format the disk?
Personally I don't mind that much about which tool formatted the hard
disk, I was only pondering if we need code in the kernel to treat
smaller partitions as FAT12, when these partitions are created as FAT16
on the Atari side.
On 27/10/20 6:13 AM, Emmanuel Kasper wrote:
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 226:48:45 |
| Calls: | 6,624 |
| Calls today: | 6 |
| Files: | 12,171 |
| Messages: | 5,318,701 |