Mkfs.fat on Linux vs. OS/2 2.1

38 pointsposted a year ago
by zdw
(uninformativ.de)

14 Comments

PreInternet01

a year 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.

somat

a year 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.

froh

a year ago

user name checks out ;-)

thanks for sharing this knowledge.

rwmj

a year 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

a year ago

Does nbdkit generate the correct OEM Label value? I don't believe so.

rwmj

a year 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/a2fe619c45a97fd89063...

However one definite restriction is it only serves FAT32 (not FAT16), which would be a dealbreaker for really old guests like this.

blueflow

a year ago

OS/2 2.1 (1993) cannot support FAT32 (1996) as it predates it.

blueflow

a year 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.

anthk

a year ago

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

Tepix

a year ago

Did you read the article?

anthk

a year ago

Yes; and Qemu with FreeDOS with fdisk+format might first most of the issues.

Brian_K_White

a year 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.