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 2/2] xfs: don't dirty snapshot logs for unlinked inode recovery
Date: Wed, 7 Mar 2018 17:33:48 -0600	[thread overview]
Message-ID: <896a0202-aac8-e43f-7ea6-3718591e32aa@sandeen.net> (raw)
In-Reply-To: <83696ce6-4054-0e77-b4b8-e82a1a9fbbc3@redhat.com>

Now that unlinked inode recovery is done outside of
log recovery, there is no need to dirty the log on
snapshots just to handle unlinked inodes.  This means
that readonly snapshots can be mounted without requiring
-o ro,norecovery to avoid the log replay that can't happen
on a readonly block device.

(unlinked inodes will just hang out in the agi buckets until
the next writable mount)

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 93588ea..5669525 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -1419,9 +1419,10 @@ struct proc_xfs_info {
 
 /*
  * Second stage of a freeze. The data is already frozen so we only
- * need to take care of the metadata. Once that's done sync the superblock
- * to the log to dirty it in case of a crash while frozen. This ensures that we
- * will recover the unlinked inode lists on the next mount.
+ * need to take care of the metadata.
+ * Any unlinked inode lists will remain at this point, and be recovered
+ * on the next writable mount if we crash while frozen, or create
+ * a snapshot from the frozen filesystem.
  */
 STATIC int
 xfs_fs_freeze(
@@ -1431,7 +1432,7 @@ struct proc_xfs_info {
 
 	xfs_save_resvblks(mp);
 	xfs_quiesce_attr(mp);
-	return xfs_sync_sb(mp, true);
+	return 0;
 }
 
 STATIC int


  parent reply	other threads:[~2018-03-07 23:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 23:31 [PATCH 0/2] xfs: don't require a dirty log on snapshots Eric Sandeen
2018-03-07 23:32 ` [PATCH 1/2] xfs: always check for and process unlinked inodes on mount Eric Sandeen
2018-03-08  0:41   ` Eric Sandeen
2018-03-15 12:17   ` Brian Foster
2018-03-15 12:19     ` Eric Sandeen
2018-03-15 12:41       ` Brian Foster
2018-03-07 23:33 ` Eric Sandeen [this message]
2018-03-24 16:20   ` [PATCH 2/2] xfs: don't dirty snapshot logs for unlinked inode recovery Darrick J. Wong
2018-03-26 12:46     ` Brian Foster
2018-03-27 21:17       ` Dave Chinner
2021-02-23 13:42         ` Gao Xiang
2021-02-23 14:40           ` Eric Sandeen
2021-02-23 15:03             ` Gao Xiang
2021-02-23 15:46               ` Eric Sandeen
2021-02-23 15:58                 ` Gao Xiang
2021-02-23 16:25                 ` Darrick J. Wong

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=896a0202-aac8-e43f-7ea6-3718591e32aa@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.