All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH] Btrfs: fix another orphan cleanup problem
Date: Mon, 25 Jan 2010 16:01:47 -0500	[thread overview]
Message-ID: <20100125210147.GB2204@localhost.localdomain> (raw)

Because orphan cleanup now happens well after the fs is all initialized and
such, we can run into this problem where we find orphan entries that were just
added to the fs, not ones that were added previously during a crash.  This does
not bode well for the system, and results in a couple of odd things happening,
like truncate being run on non-regular files.  In order to fix this we just
check and see if the inode has been added to the in-memory orphan list, and if
it has, set the key to it's inode number - 1 so we don't find this orphan entry
again, and continue searching.

This problem kept popping up while running xfs tests, and was 100%
reproduceable.  With this patch the problem no longer happens.  Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>
---
 fs/btrfs/inode.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index c7fbfaa..067f4b5 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2202,6 +2202,17 @@ void btrfs_orphan_cleanup(struct btrfs_root *root)
 		 * the proper thing when we hit it
 		 */
 		spin_lock(&root->list_lock);
+		if (!list_empty(&BTRFS_I(inode)->i_orphan)) {
+			/*
+			 * This inode is on the in-memory list, which means we
+			 * shouldn't be cleaning it up, move on to the next
+			 * orphan item.
+			 */
+			spin_unlock(&root->list_lock);
+			key.offset = inode->i_ino - 1;
+			iput(inode);
+			continue;
+		}
 		list_add(&BTRFS_I(inode)->i_orphan, &root->orphan_list);
 		spin_unlock(&root->list_lock);
 
-- 
1.5.4.3


             reply	other threads:[~2010-01-25 21:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-25 21:01 Josef Bacik [this message]
2010-01-26  4:19 ` [PATCH] Btrfs: fix another orphan cleanup problem Yan, Zheng 

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=20100125210147.GB2204@localhost.localdomain \
    --to=josef@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.