The persistence strategy described here (mount -t msdos -o rw /dev/fd0 /mnt) combined with a bind mount to home is a nice clever touch for saving space.

I don't know if that's also true for data integrity on physical magnetic media. FAT12 is not a journaling filesystem. On a modern drive, a crash during a write is at best, annoying while on a 3.5" floppy with a 33mhz CPU, a write operation blocks for a perceptible amount of time. If the user hits the power switch or the kernel panics while the heads are moving or the FAT is updating, that disk is gone. The article mentions sync, but sync on a floppy drive is an agonizingly slow operation that users might interrupt.

Given the 253KiB free space constraint, I wonder if a better approach would be treating the free space as a raw block device or a tiny appended partition using a log-structured filesystem designed for slow media (like a stripped down JFFS2 or something), though that might require too many kernel modules.

Has anyone out there experimented with appending a tar archive to the end of the initramfs image inplace for persistence, rather than mounting the raw FAT filesystem? It might be safer to serialize writes only on shutdown, would love more thoughts on this.

FAT can be made tolerant form the driver just like a journaled FS:

  1) mark blocks allocated in first FAT
  If a crash occurs here, then data written is incomplete, so write FAT1 with data from FAT2 discarding all changes.
  
  2) write data in sectors
  If a crash occurs here, same as before, keep old file size.
  
  3) update file size in the directory
  This step is atomic - it's just one sector to update. If a crash occurs here (file size matches FAT1), copy FAT1 to FAT2 and keep the new file size.
  
  4) mark blocks allocated in the second FAT
  If a crash occurs here, write is complete, just calculate and update free space.
  
  5) update free space

Controversial position: journaling is not as beneficial as commonly believed. I have been using FAT for decades and never encountered much in the way of data corruption. It's probably found in far more embedded devices than PCs these days.

Ps. On old good days there was not initrd and other ram disk stuff - you read entire system straight from the disk. Slackware 8 was that for sure and NetBSD (even newest one) is still doing it by default

> If the user hits the power switch or the kernel panics while the heads are moving or the FAT is updating, that disk is gone.

Makes sense, great point. I would rather use a second drive for the write disk space, if possible (I know how rare it's now to have two floppy drives, but still).

> If the user hits the power switch or the kernel panics while the heads are moving or the FAT is updating, that disk is gone.

This isn't true, I commented lower in the thread, but FAT keeps a backup table, and you can use that to restore the disk.