Comment 78 for bug 736743

* grub does not write to btrfs because of its checksum/cow stuff.
* btrfs is aware but doesn't seems to care as it says on its FAQ: "grub needs btrfs to support a reserved area" (and not "btrfs needs to implement reserved area")
* ubuntu is hit by this problem for years but it is something for either grub or btrfs to solve.

I love this "Somebody else's problem" way to deal with complicated problems...

Both grub and btrfs devs seems to not want to fix this problem by themselves as it is not a problem that hit them directly. Only distros that glue them together that face this problem. So, a distro or a "volunteer expert devel user" (that's not me) might be the one that proposes the fix.

SLES and OpenSuSE already uses btrfs rootfs for some time. Does it mean that grub-once simply does not work with them (and they are fine with it)?

I'm no Btrfs nor grub specialist but it is difficult to understand why is to difficult to write 1k from grub in today's multi TB disks...

Thinking about btrfs:

Btrfs already support nodatacow for a single file (chattr +C). Probably this is not enough but a little more might be.

If nodatacow files does not use checksum, one more problem is solved. If not, maybe it is the case to implement a "chattr +K" for "disable checksum for file". Some metadata like ctime/mtime would be out-of-sync but this is a minor issue.

For snapshots, it deals with nodatacow file doing a one-time cow (it increases the reference count). Again, a new "chattr +n" for "duplicate file blocks on snapshot" would keep the file block dedicated for that "copy" (duplicating data). An alternative would be grub checking the "reference count" of grubenv and avoid a write if >1. In a "best effort", ubuntu should duplicate the grubenv file whenever its "reference count" is >1 on shutdown.

Maybe all too complicated...

Thinking about grub:

In old disk format, where the first partition starts at sector 63, I guess it is already difficult to have btrfs support in grub. The last time I tried, it failed to write all needed modules. So, writing to btrfs is the last problem to deal as there is no space even for reading btrfs. For new partitions, grub has plenty of space as the first partition starts at sector 2048. In this case, grub do have a spare 1k in 1M of space. So, load_env could accept an alternative storage location based on blocks or just after the last module. This might be easier than write to any FS out there. The only problem is that grub-editenv would need to write directly to the block device. This solution is ideal as it might solve all FS write problems related to load_env (and not only for btrfs).

And, for the record, include me in the "me too"s list of affected people.