From: Marc MERLIN <marc@merlins.org>
To: Chris Mason <clm@fb.com>, Qu Wenruo <quwenruo@cn.fujitsu.com>,
Roman Mamedov <rm@romanrm.net>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: don't delay inode ref updates during log replay
Date: Thu, 1 Jan 2015 14:58:47 -0800 [thread overview]
Message-ID: <20150101225847.GJ17254@merlins.org> (raw)
In-Reply-To: <20141231183013.GA3637@ret.masoncoding.com>
Chris, you rule, I applied this to 3.16.7 and my problem went away.
Tested-By: Marc MERLIN <marc@merlins.org>
Happy new year! :)
Marc
On Wed, Dec 31, 2014 at 01:30:13PM -0500, Chris Mason wrote:
> Commit 1d52c78afbb (Btrfs: try not to ENOSPC on log replay) added a
> check to skip delayed inode updates during log replay because it
> confuses the enospc code. But the delayed processing will end up
> skipping delayed refs from log replay because the inode itself wasn't
> put through the delayed code.
>
> This can end up triggering a warning at commit time:
>
> WARNING: CPU: 2 PID: 778 at fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty+0x32/0x34()
>
> Which is repeated for each commit because we never process the delayed ref.
>
> The fix used here is to change btrfs_delayed_delete_inode_ref to return
> an error if we're current in log replay. The caller will do the ref
> deletion immediately and everything will work properly.
>
> This bug can cause lost files, whick fsck will find. --repair on
> btrfs-progs 3.18 will fix them
>
> Signed-off-by: Chris Mason <clm@fb.com>
> cc: stable@vger.kernel.org # v3.18 and any stable series that picked 1d52c78afbbf80b58299e076a159617d6b42fe3c
>
> diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
> index 054577b..de4e70f 100644
> --- a/fs/btrfs/delayed-inode.c
> +++ b/fs/btrfs/delayed-inode.c
> @@ -1857,6 +1857,14 @@ int btrfs_delayed_delete_inode_ref(struct inode *inode)
> {
> struct btrfs_delayed_node *delayed_node;
>
> + /*
> + * we don't do delayed inode updates during log recovery because it
> + * leads to enospc problems. This means we also can't do
> + * delayed inode refs
> + */
> + if (BTRFS_I(inode)->root->fs_info->log_root_recovering)
> + return -EAGAIN;
> +
> delayed_node = btrfs_get_or_create_delayed_node(inode);
> if (IS_ERR(delayed_node))
> return PTR_ERR(delayed_node);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
next prev parent reply other threads:[~2015-01-01 22:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-28 19:26 3.16.3: fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty Marc MERLIN
2014-12-28 20:00 ` Roman Mamedov
2014-12-28 21:36 ` Marc MERLIN
2014-12-29 15:17 ` Chris Mason
2014-12-29 15:41 ` Marc MERLIN
2014-12-29 15:57 ` Chris Mason
2014-12-30 1:06 ` Qu Wenruo
2014-12-31 18:30 ` [PATCH] Btrfs: don't delay inode ref updates during log replay Chris Mason
2015-01-01 22:58 ` Marc MERLIN [this message]
2015-01-02 0:44 ` Qu Wenruo
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=20150101225847.GJ17254@merlins.org \
--to=marc@merlins.org \
--cc=clm@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
--cc=rm@romanrm.net \
/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.