Re: Atomic writing to environment file

[Lennart Sorensen]

On Tue, Feb 16, 2021 at 08:44:43AM +0100, Claudius Heine wrote:
> we were looking into using grub to implement an A/B system update mechanism
> [1] and came to the point where we need to change the grub environment from
> user space (grub-editenv) and from grub itself (save_env).
> 
> We looked at the code [2] and [3], and it sort of looks like the environment
> file is written directly in both cases. We suspect that this might cause the
> environment file to become invalid/empty in a power-loss scenario.
> 
> Other write schemes, like: `write file.tmp; mv file.tmp file` or using
> hard-links (if the fs supports it) might provide a better protection against
> a power-loss scenario.
> 
> If this is an issue, then we would be willing to contribute some changes to
> grub for this.
> 
> kind regards,
> Claudius Heine
> 
> [1]
> https://sbabic.github.io/swupdate/overview.html#double-copy-with-fall-back
> [2] 
> https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/commands/loadenv.c#n380
> [3] https://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-editenv.c#n186

Of course the current method conviniently doesn't need to fully understand
a filesystem, it just needs to update the existing block's contents.
Of course on filesystems like zfs that has checksums, that would still
need to be updated too somehow.

I was under the impression grub really only implemented enough filesystem
code to read the filesystems, not write them.

I guess one method that could work in a simple way was to have two files
and put a version number in each one, and update it each time you write to
one after you updated the contents to make the updated file the newest.
Of course I am not sure if any disk really has any problem with sector
level updates being partially done or if they ever promise that you will
always get complete sector updates.

-- 
Len Sorensen