On 18/09/2018 20.52, Chris Murphy wrote: > On Tue, Sep 18, 2018 at 11:15 AM, Goffredo Baroncelli > <kreijack@xxxxxxxxx> 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? On this statement I fully agree, on the one below a bit less > > 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. Also the 'suse' behavior have the same issue: storing the data somewhere in the storage reserved area suffers of the same problem. We should be realistic, without implement a full btrfs filesystem engine, it is near impossible to have a grubenv file visible by the filesystem and snapshot-able. > > 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 Not yet, I am working on that [1] > but is the bootloader overwrite of gruvenv going to > recompute parity and write to multiple devices? Eek! Recompute the parity should not be a big deal. Updating all the (b)trees would be a too complex goal. > > [1] http://lists.gnu.org/archive/html/grub-devel/2018-06/msg00064.html -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
