[ 3.5.y.z extended stable ] Patch "Btrfs: use set_nlink if our i_nlink is 0" has been added to staging queue
Luis Henriques
luis.henriques at canonical.com
Wed Apr 3 10:50:56 UTC 2013
This is a note to let you know that I have just added a patch titled
Btrfs: use set_nlink if our i_nlink is 0
to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Luis
------
>From db1131f3fb73bbe84c5c82c798690887510b44dc Mon Sep 17 00:00:00 2001
From: Josef Bacik <jbacik at fusionio.com>
Date: Fri, 1 Mar 2013 13:35:47 -0500
Subject: [PATCH] Btrfs: use set_nlink if our i_nlink is 0
commit 9bf7a4890518186238d2579be16ecc5190a707c0 upstream.
We need to inc the nlink of deleted entries when running replay so we can do the
unlink on the fs_root and get everything cleaned up and then have the orphan
cleanup do the right thing. The problem is inc_nlink complains about this, even
thought it still does the right thing. So use set_nlink() if our i_nlink is 0
to keep users from seeing the warnings during log replay. Thanks,
Signed-off-by: Josef Bacik <jbacik at fusionio.com>
[ luis: adjust context ]
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
---
fs/btrfs/tree-log.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 8abeae4..aad8644 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1132,7 +1132,10 @@ static noinline int link_to_fixup_dir(struct btrfs_trans_handle *trans,
btrfs_release_path(path);
if (ret == 0) {
- btrfs_inc_nlink(inode);
+ if (!inode->i_nlink)
+ set_nlink(inode, 1);
+ else
+ btrfs_inc_nlink(inode);
btrfs_update_inode(trans, root, inode);
} else if (ret == -EEXIST) {
ret = 0;
--
1.8.1.2
More information about the kernel-team
mailing list