linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com, linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: quiesce the filesystem after recovery on readonly mount
Date: Sat, 24 Sep 2016 08:21:53 +1000	[thread overview]
Message-ID: <20160923222153.GQ340@dastard> (raw)
In-Reply-To: <f693b1a2-1cdb-ed9f-caa0-af9407034927@sandeen.net>

On Fri, Sep 23, 2016 at 11:24:53AM -0500, Eric Sandeen wrote:
> On 9/22/16 8:39 PM, Eric Sandeen wrote:
> > On 9/22/16 7:11 PM, Dave Chinner wrote:
> >> From: Dave Chinner <dchinner@redhat.com>
> 
> ...
> 
> >> To avoid this problem, we need to ensure that a read-only mount
> >> always updates the log when it completes the second phase of
> >> recovery. We already handle this sort of issue with rw->ro remount
> >> transitions, so the solution is as simple as quiescing the
> >> filesystem at the appropriate time during the mount process. This
> >> results in the log being marked clean so the mount behaviour
> >> recorded in the logs on repeated RO mounts will change (i.e. log
> >> recovery will no longer be run on every mount until a RW mount is
> >> done). This is a user visible change in behaviour, but it is
> >> harmless.
> > 
> > Excellent idea :)
> > 
> > Reviewed-by: Eric Sandeen <sandeen@redhat.com>
> 
> Actually ...  after playing with this a bit ...
> 
> Should we restrict this to only when the log got
> replayed, with a !XFS_LAST_UNMOUNT_WAS_CLEAN(mp) test?
> 
> Maybe it's harmless as it is, but it seems we should restrict
> it to the log-got-replayed case.

Well, writing another unmount record should be harmless. The thing
is that the quiesce call also serves to shut down periodic log
functions that are started when the second phase of recovery is run,
These are started regardless of whether the mount was clean or not.
Hence we are currently running periodic log work on ro mounts and
tryin gto cover/sync the log every so often. For rw mounts this is
needed, but for ro mounts once we know everything is clean we can
shut them down, jus tlike we do for a rw->ro remount.

So I think that just treating the ro mount like a rw mount followed
by a rw->ro transition after potential mount time modifications are
complete is the best approach for consistency of RO behaviour....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2016-09-23 22:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-23  0:11 [PATCH] xfs: quiesce the filesystem after recovery on readonly mount Dave Chinner
2016-09-23  1:39 ` Eric Sandeen
2016-09-23 16:24   ` Eric Sandeen
2016-09-23 22:21     ` Dave Chinner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160923222153.GQ340@dastard \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).