Re: [PATCH 3/3] xfs: freeze rw filesystems just prior to reboot

[Dave Chinner <david@fromorbit.com>]

On Mon, May 22, 2017 at 11:04:54PM -0500, Eric Sandeen wrote:
> On 5/22/17 10:56 PM, Chris Murphy wrote:
> > On Mon, May 22, 2017 at 2:46 PM, Chris Murphy <lists@colorremedies.com> wrote:
> > 
> >> Second, I have only been able to reproduce this problem with grubby +
> >> XFS.
> > 
> > OK so this is just on Fedora/RH systems, which is the example case I
> > have. The kernel RPM is running a script called new-kernel-pkg which
> > is part of grubby. It's found here:
> > 
> > https://github.com/rhinstaller/grubby/blob/master/new-kernel-pkg
> > 
> > # make sure changes make it to the disk.
> > # if /boot is a mountpoint, force the meta data on disk
> > # to by-pass writeback delay.
> > # PPC64LE-only to deal with Petitboot issues
> > if [ "$ARCH" = "ppc64le" ]; then
> >     sync && mountpoint -q /boot && fsfreeze -f /boot && fsfreeze -u /boot
> > fi
> > 
> > 
> > So why only Petitboot on ppc64 is considered to need this?

> because petitboot essentially a full kernel & userspace, and it is
> (may be?) a different endianness than the os and the filesystem it's booting...
> so normally it actually /could/ replay the log, but it can't due to the
> different endianness.  So, freeze / unfreeze to quiesce, and then
> petitboot does mount -o norecovery to ignore the unmount record we leave
> lying around on a frozen fs.

Actually, IIUC what Stewart told me at LCA earlier this year, what
petitboot does now is far more convoluted and whacky than mount -o
norecovery. It overlays a write-capturing ram disk on top of the
block device, mounts the filesystem and performs log recovery.  All
writes from log recovery go into the ram disk so it never modifies
the underlying block device. It then traverses the recovered
filesystem to find the kernel images, and once they are found it
boots from them, throwing away the ramdisk that contained the
recovered changes from the log.

> Hacks upon hacks.

It's hacks all the way down....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com