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

[Dave Chinner <david@fromorbit.com>]

On Wed, May 24, 2017 at 12:22:13AM -0600, Chris Murphy wrote:
> Something seems really out of order here.

Intentionally so.

Filesystems do screwy, complex things to extract maximum performance
whilst maintaining operational ordering.  We use log sequence
numbers to ensure the order of operations is maintained correctly in
the active portion of the journal, but we provide no ordering
guarantees for metadata writeback operations from the journal.

> The kernel is installed
> first, then the initramfs is built, grub.cfg.new is created, grub.cfg
> is deleted, grub.cfg.new is renamed to grub.cfg. How is it the first
> two items are in the dirty log, not fully committed to fs metadata;
> but the grub.cfg is zero length?  Why isn't the old one still there as
> far as grub is concerned? If that were the case, the old kernel and
> initramfs could be booted and then the log replayed to fix up
> everything. The ordering here seems pretty screwy.

By mounting "-o ro,norecovery" what you are seeing is evidence of
metadata being flushed from the journal in optimal IO order rather
than strict sequence order. The filesystem is not in a consistent
state if you haven't recovered the journal. Recovering the journal
(i.e. a normal mount) replays all the recorded changes and intents
in strict sequence order, hence providing the high level operational
ordering semantics we guarantee users.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com