[Fiveplus]

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.

[userbinator]

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.

[Skunkleton]

If you make structural changes to your filesystem without a journal, and you fail mid way, there is a 100% chance your filesystem is not in a known state, and a very good chance it is in a non-self-consistent state that will lead to some interesting surprises down the line.

[ars]

FAT has two allocation tables, the main one and a backup. So if you shut it off while manipulating the first one you have the backup. You are expected to run a filesystem check after a power failure.

[userbinator]

No, it is very well known what will happen: you can get lost cluster chains, which are easily cleaned up. As long as the order of writes is known, there is no problem.

[dezgeg]

Better hope you didn't have a rename in progress with the old name removed without the new name in place. Or a directory entry written pointing to a FAT chain not yet committed to the FAT.

Yes, soft updates style write ordering can help with some of the issues, but the Linux driver doesn't do that. And some of the issues are essentially unavoidable, requiring a a full fsck on each unclean shutdown.

[M95D]

I don't know how Linux driver updates FAT, but if it doesn't do it the way DOS did, then it's a bug that puts data at risk.

1) Allocate space in FAT#2, 2) Write data in file, 3) Allocate space in FAT#1, 4) Update directory entry (file size), 5) Update free space count.

Rename in FAT is an atomic operation. Overwrite old name with new name in the directory entry, which is just 1 sector write (or 2 if it has a long file name too).

[dezgeg]

No, the VFAT driver doesn't do anything even slightly resembling that.

In general "what DOS did" doesn't cut for a modern system with page and dentry caches and multiple tasks accessing the filesystem without completely horrible performance. I would be really surprised if Windows handled all those cases right with disk caching enabled.

While rename can be atomic in some cases, it cannot be in the case of cross directory renames or when the new filename doesn't fit in the existing directory sector.

[M95D]

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

[ale42]

Is this something the FAT driver is Linux can do?

[dezgeg]

No. There are proprietary implementations which can, though not in 100% of the cases.

[iberator]

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

[anthk]

Slackware has several kernels to choose from.

[zx8080]

> 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).

[M95D]

OpenWrt on some devices such as Turris Omnia writes the squashfs (mounted as RO root fs) in the "root" partition and then, immediately after, in the same partition, it writes a jffs2 (mounted as RW overlayfs). So it can be done.

[ars]

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