BLS: suggest fixed-width boot counters for atomic updates on FAT32

[nkraetzschmar]

This PR extends the "Boot counting" section to specify that boot counter fields should be fixed-width and pre-initialized, in order to keep rename operations atomic on FAT32 filesystems.

On FAT32, long filenames are implemented as a series of consecutive LFN entries. When the filename length changes (e.g. when adding the "tries done" suffix), the filesystem may need to reallocate directory entries and move existing ones around. This can require rewriting multiple sectors and is not guaranteed to be atomic. In worst case, a power loss during such an operation could leave partial LFN chains or break other directory entries.

By requiring fixed-width counters and pre-initializing the "tries-done" field, we can ensure that boot counter updates do not change the filename length, and thus avoid triggering potentially non-atomic operations.

Obviously this would be a breaking change in the spec, so it might be more appropriate to phrase this as a recommendation rather than a requirement. I'd love some input on which of the two directions would be preferable, and I'm happy to reword this if the more suggestion-based approach is considered better.

[jluebbe]

@nkraetzschmar Do you know which FAT32 implementations guarantee atomic updates in this case?

[nkraetzschmar]

Thanks for your question. This idea was initially motivated purely by the FAT32 on-disk format (contiguous LFN entries immediately preceding the 8.3 entry), not by any particular implementation.

After your question I did dig into both the kernels implementation and that of EDK2 (likely the two most relevant ones here). Rename behavior there is a tad bit more nuanced than I first assumed:

EDK2

• Removes the original directory entry set (marks it deleted).
• Then creates a new entry set for the new name.
• If the LFN does not grow, the allocator will often re-use the just freed slots in the same directory cluster.
• If the LFN does grow, and subsequent entries are already in the way, it has to place the new set elsewhere. If the directory has no room, it may also need to extend the directory (allocate new clusters and link them into the chain).

Linux

• Creates the new entry set first, then marks the old one deleted.
• This means even same length renames require finding new contiguous slots. If the directory is full, it may extend the directory regardless of whether the LFN length changed.

Note: I'm not claiming deep expertise in either EDK2 or the kernel vfat filesystem code... this is a surface-level read and should be taken with a healthy grain of salt

Takeaway: it still seems beneficial to avoid increasing the filename length. In EDK2's case (arguably most important in boot contexts), keeping the LFN size constant should let the rename re-use existing space and avoid growing the directory's cluster chain. It's not a 100% bulletproof guarantee to be atomic, but at least it minimizes the likelihood of growing the directory cluster.

[poettering]

I think this makes sense. the PR title said "require", even though the spec changes say "should". I think "should" is right though, we should not make this a strict requirement, already to not break compat needlessly.

hence, I think this can go in as is.

And yes, even if the current drivers don't implement things like this, the spec should still cover things so that well behaving drivers could be fixed to follow this.