On Fri, Apr 20, 2018 at 5:49 PM, Chris Adams <linux@xxxxxxxxxxx> wrote: > Once upon a time, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> said: >> And sync() is only sufficient on non-journaled file >> systems, on journaled file systems sync() only ensures metadata is in >> the log, it's considered acceptable to depend on log replay to make >> the file system consistent, but of course the bootloader can't do >> that. > > So, to me, this is the bug. GRUB claims to read XFS, but it only reads > XFS in certain states (and doesn't throw an error if the filesystem is > in any other state, just fails). If GRUB can't read XFS in the common > reasonable states, then it shouldn't claim XFS support, and Fedora > shouldn't be using XFS for any filesystem GRUB needs to read. > > That IMHO would mean one of: > > - fix GRUB to be able to handle the XFS journal in some form Discussed on XFS devel, and considered overly complicated to deal with the memory requirements and effectively two different code bases that would result. > - change Fedora so that if there's a /boot, it gets ext2 > - change Fedora so that otherwise, don't use XFS for / It's valid to use this to exemplify the absurdity of the problem. But it's as impractical as throwing the baby out with the bathwater. Nothing is actually being fixed with these changes, and worse it ignores the fundamental problem with /boot modifying programs. > I understand not handling significant filesystem errors, but "file is in > the journal" shouldn't be one of them. And there's a prescribed solution by fs devs for this: FIFREEZE/FITHAW Only recently did grubby start doing an fsync after grub.cfg is renamed, and grub-mkconfig doesn't use sync of any variety at all ever. Seems to me they were designed with the assumption /boot would be cleanly unmounted and I don't think that's reasonable. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
