Displaying 9 results from an estimated 9 matches for "i_orphan".
2012 Apr 20
44
Ceph on btrfs 3.4rc
After running ceph on XFS for some time, I decided to try btrfs again.
Performance with the current "for-linux-min" branch and big metadata
is much better. The only problem (?) I''m still seeing is a warning
that seems to occur from time to time:
[87703.784552] ------------[ cut here ]------------
[87703.789759] WARNING: at fs/btrfs/inode.c:2103
2011 Sep 21
3
[PATCH] Btrfs: fix orphan cleanup regression
...ret = PTR_ERR(inode);
+ ret = PTR_RET(inode);
+ if (ret && ret != -ESTALE)
goto out;
- }
-
- /*
- * add this inode to the orphan list so btrfs_orphan_del does
- * the proper thing when we hit it
- */
- spin_lock(&root->orphan_lock);
- list_add(&BTRFS_I(inode)->i_orphan, &root->orphan_list);
- spin_unlock(&root->orphan_lock);
/*
- * if this is a bad inode, means we actually succeeded in
- * removing the inode, but not the orphan record, which means
- * we need to manually delete the orphan since iput will just
- * do a destroy_inode
+...
2008 Jun 24
1
[RFC][PATCH] btrfs orphan code
...-r 99b12e2db0f8 btrfs_inode.h
--- a/btrfs_inode.h Wed Jun 18 20:50:41 2008 -0400
+++ b/btrfs_inode.h Tue Jun 24 21:04:39 2008 -0400
@@ -36,6 +36,9 @@ struct btrfs_inode {
struct posix_acl *i_acl;
struct posix_acl *i_default_acl;
+ /* for keeping track of orphaned inodes */
+ struct list_head i_orphan;
+
u64 ordered_trans;
/*
* transid of the trans_handle that last modified this inode
diff -r 99b12e2db0f8 ctree.h
--- a/ctree.h Wed Jun 18 20:50:41 2008 -0400
+++ b/ctree.h Tue Jun 24 21:04:39 2008 -0400
@@ -103,7 +103,8 @@ extern struct kmem_cache *btrfs_path_cac
#define BTRFS_FT_SOCK 6...
2011 Nov 30
1
[PATCH] Canonicalise BTRFS: and Btrfs: to btrfs:
..."[%llu %llu]\n", (unsigned long long)em->start,
(unsigned long long)em->len,
(unsigned long long)start,
@@ -6693,7 +6693,7 @@ void btrfs_destroy_inode(struct inode *inode)
spin_lock(&root->orphan_lock);
if (!list_empty(&BTRFS_I(inode)->i_orphan)) {
- printk(KERN_INFO "BTRFS: inode %llu still on the orphan list\n",
+ printk(KERN_INFO "btrfs: inode %llu still on the orphan list\n",
(unsigned long long)btrfs_ino(inode));
list_del_init(&BTRFS_I(inode)->i_orphan);
}
--
1.7.4.1
--
Chris Samuel :...
2010 Jan 25
1
[PATCH] Btrfs: fix another orphan cleanup problem
...e.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(&BTR...
2011 Nov 09
12
WARNING: at fs/btrfs/inode.c:2198 btrfs_orphan_commit_root+0xa8/0xc0
Hello,
I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using
the 3.1 kernel, I found a patch for these warnings (
http://marc.info/?l=linux-btrfs&m=131547325515336&w=2)
<http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch
has already been included in 3.1. Are there any other patches I can try?
I''m using
2009 Nov 12
0
[PATCH 05/12] Btrfs: Avoid orphan inodes cleanup during replaying log
...ret = btrfs_search_slot(NULL, root, &key, path, 0, 0);
if (ret < 0) {
@@ -3293,6 +3294,11 @@ void btrfs_delete_inode(struct inode *inode)
}
btrfs_wait_ordered_range(inode, 0, (u64)-1);
+ if (root->fs_info->log_root_recovering) {
+ BUG_ON(!list_empty(&BTRFS_I(inode)->i_orphan));
+ goto no_delete;
+ }
+
if (inode->i_nlink > 0) {
BUG_ON(btrfs_root_refs(&root->root_item) != 0);
goto no_delete;
@@ -3700,6 +3706,13 @@ struct inode *btrfs_lookup_dentry(struct inode *dir, struct dentry *dentry)
}
srcu_read_unlock(&root->fs_info->subvol_srcu,...
2011 May 11
8
[PATCH 1/4] Btrfs: map the node block when looking for readahead targets
If we have particularly full nodes, we could call btrfs_node_blockptr up to 32
times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the
extent buffer while we look for readahead targets. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
---
fs/btrfs/ctree.c | 23 +++++++++++++++++++++--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git
2011 Jun 21
19
[GIT PULL v3] Btrfs: improve write ahead log with sub transaction
I''ve been working to try to improve the write-ahead log''s performance,
and I found that the bottleneck addresses in the checksum items,
especially when we want to make a random write on a large file, e.g a 4G file.
Then a idea for this suggested by Chris is to use sub transaction ids and just
to log the part of inode that had changed since either the last log commit or
the last