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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel