On Wed, May 17, 2017 at 06:32:42PM -0700, Darrick J. Wong wrote: > Apparently there are certain system software configurations that do odd > things like update the kernel and reboot without umounting the /boot fs > or remounting it readonly, either of which would push all the AIL items > out to disk. As a result, a subsequent invocation of something like > grub (which has a frightening willingness to read a fs with a dirty log) > can read stale disk contents and/or miss files the metadata for which > have been written to the log but not checkpointed into the filesystem. > Granted, most of the time /boot is a separate partition and > systemd/sysvinit/whatever actually /do/ unmount /boot before rebooting. > This "fix" is only needed for people who have one giant filesystem. Let me guess the series of events: grub calls "sync" and says "I'm done", then user runs an immediate reboot/shutdown and something still running after init has killed everything but PID 1 has an open writeable file descriptor causing the remount-ro of / to return EBUSY and so it just shuts down/restarts with an unflushed log? > Therefore, add a reboot hook to freeze the rw filesystems (which > checkpoints the log) just prior to reboot. This is an unfortunate and > insufficient workaround for multiple layers of inadequate external > software, but at least it will reduce boot time surprises for the "OS > updater failed to disengage the filesystem before rebooting" case. > > Seeing as grub is unlikely ever to learn to replay the XFS log (and we > probably don't want it doing that), If anything other than XFS code modifies the filesystem (log, metadata or data) then we have a tainted, unsuportable filesystem image..... > *LILO has been discontinued for at least 18 months, Yet Lilo still works just fine. > and we're not quite to the point of putting kernel > files directly on the EFI System Partition, Really? How have we not got there yet - we were doing this almost 15 years ago with ia64 and elilo via mounting the EFI partition on /boot.... > this seems like the least > crappy solution to this problem. > > Yes, you're still screwed in grub if the system crashes. :) This really sounds like the perennial "grub doesn't ensure the information it requires to boot is safely on stable storage before reboot" problem combined with some sub-optimal init behaviour to expose the grub issue.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
