On Fri, Apr 20, 2018 at 5:32 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Fri, Apr 20, 2018 at 1:23 PM, Chris Adams <linux@xxxxxxxxxxx> wrote: >> Another solution might be to have a dnf plugin that forces a journal >> flush (not a bad idea in general after loading updates), but that would >> be kind of a band-aid over this problem. > > It's a good anecdote showing that separate /boot isn't a sure solution > for this problem. > > The central problem is bad design, wrong assumptions, by grubby and > GRUB (grub-mkconfig). They both assume something else will commit the > changes to /boot that add kernel, initramfs, and bootloader > configuration. 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. And that's why whatever modifies /boot last is most responsible > for making sure the changes are fully committed, and the only way to > do that on a journaled file system is freeze/thaw. The command line tool "sync" or something like it used to be a critical step, even before Linux, in shutting down operating systems. In the meantime, does the "sync" command line tool do a full "freeze/thaw"? Is there such a tool right now, one that can be incorporated as an optional procedure for people using XFS and installing new kernels, until this can be resolved? I can well understand that the "sync" command line tool can cause a system lockup if there is media that is mounted but unresponsive, such as network drives or disabled storage media. It can also cause a real performance hit to run "sync" on a very, very busy system. end an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
