All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Eric Sandeen <sandeen@redhat.com>, linux-xfs <linux-xfs@vger.kernel.org>
Subject: [PATCH 1/2] xfs: write unmount record for ro mounts
Date: Fri, 21 Jul 2017 10:24:28 -0500	[thread overview]
Message-ID: <94b5e8b2-64cf-8945-83ff-15336f64e1b6@sandeen.net> (raw)
In-Reply-To: <e98c7179-fdb0-1cc7-544b-c55489451db5@redhat.com>

There are dueling comments in the xfs code about intent
for log writes when unmounting a readonly filesystem.

In xfs_mountfs, we see the intent:

/*
 * Now the log is fully replayed, we can transition to full read-only
 * mode for read-only mounts. This will sync all the metadata and clean
 * the log so that the recovery we just performed does not have to be
 * replayed again on the next mount.
 */

and it calls xfs_quiesce_attr(), but by the time we get to 
xfs_log_unmount_write(), it returns early for a RDONLY mount:

 * Don't write out unmount record on read-only mounts.

Because of this, sequential ro mounts of a filesystem with
a dirty log will replay the log each time, which seems odd.

Fix this by writing an unmount record even for RO mounts, as long
as norecovery wasn't specified (don't write a clean log record
if a dirty log may still be there!) and the log device is
writable.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
---


diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index 0053bcf..0bd1341 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -801,11 +801,14 @@
 	int		 error;
 
 	/*
-	 * Don't write out unmount record on read-only mounts.
+	 * Don't write out unmount record on norecovery mounts or ro devices.
 	 * Or, if we cd are doing a forced umount (typically because of IO errors).
 	 */
-	if (mp->m_flags & XFS_MOUNT_RDONLY)
+	if (mp->m_flags & XFS_MOUNT_NORECOVERY ||
+	    xfs_readonly_buftarg(log->l_mp->m_logdev_targp)) {
+		ASSERT(mp->m_flags & XFS_MOUNT_RDONLY);
 		return 0;
+	}
 
 	error = _xfs_log_force(mp, XFS_LOG_SYNC, NULL);
 	ASSERT(error || !(XLOG_FORCED_SHUTDOWN(log)));



  reply	other threads:[~2017-07-21 15:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 15:10 [PATCH 0/2 resend] xfs: readonly handling changes Eric Sandeen
2017-07-21 15:24 ` Eric Sandeen [this message]
2017-08-11 13:02   ` [PATCH 1/2] xfs: write unmount record for ro mounts Christoph Hellwig
2017-07-21 15:25 ` [PATCH 2/2] xfs: toggle readonly state around xfs_log_mount_finish Eric Sandeen
2017-08-11 13:03   ` Christoph Hellwig
2017-08-11 19:45   ` [PATCH 2/2 V2] " Eric Sandeen
2017-08-11 19:47     ` Darrick J. Wong
  -- strict thread matches above, loose matches on Subject: below --
2017-03-09 19:40 [PATCH 0/2] xfs: readonly handling changes Eric Sandeen
2017-03-09 20:15 ` [PATCH 1/2] xfs: write unmount record for ro mounts Eric Sandeen
2017-03-15 15:18   ` Brian Foster

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=94b5e8b2-64cf-8945-83ff-15336f64e1b6@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.