On Tue, Sep 18, 2018 at 11:15 AM, Goffredo Baroncelli <kreij...@libero.it> wrote: > On 18/09/2018 06.21, Chris Murphy wrote: >> b. The bootloader code, would have to have sophisticated enough Btrfs >> knowledge to know if the grubenv has been reflinked or snapshot, >> because even if +C, it may not be valid to overwrite, and COW must >> still happen, and there's no way the code in GRUB can do full blow COW >> and update a bunch of metadata. > > And what if GRUB ignore the possibility of COWing and overwrite the data ? Is > it a so big problem that the data is changed in all the snapshots ? > It would be interested if the same problem happens for a swap file.....
I think it's an abomination :-) It totally perverts the idea of reflinks and snapshots and blurs the line between domains. Is it a user file or not and are these user space commands or not and are they reliable or do they have exceptions? I have a boot subvolume mounted at /boot, and this boot subvolume gets snapshot, and if GRUB can overwrite grubenv, it overwrites the purported GRUB state information in every one of those boots, going back maybe months, even when these are read only subvolumes. I think it's a problem, and near as I can tell it'll be a problem for all kinds of complex storage. I don't see how the bootloader itself can do an overwrite onto raid5 or raid6. That's certainly supported by GRUB for reading, but is the bootloader overwrite of gruvenv going to recompute parity and write to multiple devices? Eek! -- Chris Murphy
