4 ms·

Mkfs.fat on Linux vs. OS/2 2.1

38 points by zdw 2y ago

anthk 2y ago
mkfs.vfat -F 16. Also a FreeDOS boot disk could work too, with Qemu.
- Tepix 2y ago
  Did you read the article?
  - anthk 2y ago
    Yes; and Qemu with FreeDOS with fdisk+format might first most of the issues.
    - Brian_K_White 2y ago
      How did you read the article and still suggest this? Are you actually suggesting to script launching qemu to run a freedos image to run fdisk within that to generate arbitrary dos disk images on the fly? Just to output a few bytes different? The entire job, once understood, is barely an echo command in bash.
  - yjftsjthsd-h 2y ago
    https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
PreInternet01 2y ago
> The rest of the "Extended BIOS Parameter Block" looks like it isn't relevant data, like the volume label or the volume's serial number No, that's the exact reason why OS/2 checks the OEM ID. The volume label was initially used to detect disk swaps (so that if an application has open files on disk 1, it does not destroy data on disk 2 by writes after the user replaces the floppy in the drive, which could not be detected in hardware until much later, and even then not unless you were using a Mac, basically). Of course, the volume label is user-set (so duplicates are possible), and more often not set than meaningful in any case. So, DOS 3.3 added the (unique-at-format-time) volume serial number. Which was always all-zeroes (or garbage) on pre-3.3 disks, hence the need for the OEM ID check.
- froh 2y ago
  user name checks out ;-) thanks for sharing this knowledge.
- somat 2y ago
  Does that mean it needs to seek to and from the volume label/volume info blocks for every single read or write? It sounds like that would kill performance, at a time when you needed all the performance you could get. I suppose it could be amortized, something like only check the volume headers if it has been more than 10 seconds since the last read/write.
  - PreInternet01 2y ago
    No, I'm pretty sure this check was only done when the (root) directory needed to be accessed, which was on the same track as the boot sector, so reading it (which was required for synchronization anyway) was free. Glancing at https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/BIOS/MSDISK.ASM#L708 https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/BIOS/... seems to support this...
blueflow 2y ago
maximum control over your DOS filesystems: Create the boot sector with nasm and have mformat -B (from mtools) fill in the disk geometry. For devices with CHS addressing, information in the BPB is crucial for getting the CHS geometry. It has to match how the medium was formatted.
rwmj 2y ago
Doesn't mention what hypervisor is used (qemu? bochs?) but if it speaks NBD then you can do: $ nbdkit floppy /path/to/some/directory which will serve the data in that directory as a floppy disk over NBD on port 10809. In qemu you can attach this with -drive nbd:localhost:10809. It doesn't use mkfs.fat, instead a custom FAT generator, and I think people have used it with ancient guests (however I'd have to check to be sure, either way should be easy to patch).
- blueflow 2y ago
  Does nbdkit generate the correct OEM Label value? I don't believe so.
  - rwmj 2y ago
    I thought someone had sent me a fix for this in the distant past, but I can't find the "MSDOSxxx" label in the source. However the custom generator should be easy to fix: https://gitlab.com/nbdkit/nbdkit/-/blob/a2fe619c45a97fd89063cc8d9106264c5adf6018/plugins/floppy/virtual-floppy.c#L454 https://gitlab.com/nbdkit/nbdkit/-/blob/a2fe619c45a97fd89063... However one definite restriction is it only serves FAT32 (not FAT16), which would be a dealbreaker for really old guests like this.
    - blueflow 2y ago
      OS/2 2.1 (1993) cannot support FAT32 (1996) as it predates it.

38 points by zdw 2y ago

anthk 2y ago

mkfs.vfat -F 16. Also a FreeDOS boot disk could work too, with Qemu.

Tepix 2y ago
Did you read the article?
- anthk 2y ago
  Yes; and Qemu with FreeDOS with fdisk+format might first most of the issues.
  - Brian_K_White 2y ago
    How did you read the article and still suggest this? Are you actually suggesting to script launching qemu to run a freedos image to run fdisk within that to generate arbitrary dos disk images on the fly? Just to output a few bytes different? The entire job, once understood, is barely an echo command in bash.
- yjftsjthsd-h 2y ago
  https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".

PreInternet01 2y ago

> The rest of the "Extended BIOS Parameter Block" looks like it isn't relevant data, like the volume label or the volume's serial number No, that's the exact reason why OS/2 checks the OEM ID. The volume label was initially used to detect disk swaps (so that if an application has open files on disk 1, it does not destroy data on disk 2 by writes after the user replaces the floppy in the drive, which could not be detected in hardware until much later, and even then not unless you were using a Mac, basically). Of course, the volume label is user-set (so duplicates are possible), and more often not set than meaningful in any case. So, DOS 3.3 added the (unique-at-format-time) volume serial number. Which was always all-zeroes (or garbage) on pre-3.3 disks, hence the need for the OEM ID check.

froh 2y ago
user name checks out ;-) thanks for sharing this knowledge.
somat 2y ago
Does that mean it needs to seek to and from the volume label/volume info blocks for every single read or write? It sounds like that would kill performance, at a time when you needed all the performance you could get. I suppose it could be amortized, something like only check the volume headers if it has been more than 10 seconds since the last read/write.
- PreInternet01 2y ago
  No, I'm pretty sure this check was only done when the (root) directory needed to be accessed, which was on the same track as the boot sector, so reading it (which was required for synchronization anyway) was free. Glancing at https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/BIOS/MSDISK.ASM#L708 https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/BIOS/... seems to support this...

blueflow 2y ago

maximum control over your DOS filesystems: Create the boot sector with nasm and have mformat -B (from mtools) fill in the disk geometry. For devices with CHS addressing, information in the BPB is crucial for getting the CHS geometry. It has to match how the medium was formatted.

rwmj 2y ago

Doesn't mention what hypervisor is used (qemu? bochs?) but if it speaks NBD then you can do: $ nbdkit floppy /path/to/some/directory which will serve the data in that directory as a floppy disk over NBD on port 10809. In qemu you can attach this with -drive nbd:localhost:10809. It doesn't use mkfs.fat, instead a custom FAT generator, and I think people have used it with ancient guests (however I'd have to check to be sure, either way should be easy to patch).

blueflow 2y ago
Does nbdkit generate the correct OEM Label value? I don't believe so.
- rwmj 2y ago
  I thought someone had sent me a fix for this in the distant past, but I can't find the "MSDOSxxx" label in the source. However the custom generator should be easy to fix: https://gitlab.com/nbdkit/nbdkit/-/blob/a2fe619c45a97fd89063cc8d9106264c5adf6018/plugins/floppy/virtual-floppy.c#L454 https://gitlab.com/nbdkit/nbdkit/-/blob/a2fe619c45a97fd89063... However one definite restriction is it only serves FAT32 (not FAT16), which would be a dealbreaker for really old guests like this.
  - blueflow 2y ago
    OS/2 2.1 (1993) cannot support FAT32 (1996) as it predates it.