Btrfs-next fails xfstest 127 when checking length of an extent in
log_one_extent(). Fix this by doing the item type check.
Signed-off-by: Itaru Kitayama kitay...@cl.bb4u.ne.jp
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 40b9efd..0c20bb4 100644
--- a/fs/btrfs/tree-log.c
+++ b
Hi Liubo,
I couldn't apply your V4 patch against the btrfs-next HEAD. Do you have
a github branch which I can checkout?
Thanks,
Itaru
On Wed, Oct 31, 2012 at 9:55 PM, Liu Bo bo.li@oracle.com wrote:
On 10/31/2012 08:13 PM, Itaru Kitayama wrote:
Hi LiuBo:
I am seeing another warning
Hi LiuBo:
I am seeing another warning with your patch applied btrfs-next.
[ 5224.531560] [ cut here ]
[ 5224.531565] WARNING: at fs/btrfs/inode.c:2054
record_extent_backrefs+0x87/0xe0()
[ 5224.531567] Hardware name: Bochs
[ 5224.531568] Modules linked in: microcode ppdev
to examine the mechanisms
implemented there are
working as expected.
Thanks,
Itaru
On Mon, Oct 1, 2012 at 7:29 AM, David Sterba d...@jikos.cz wrote:
Hi again,
On Sun, Sep 30, 2012 at 11:11:10AM +0900, Itaru Kitayama wrote:
This is the correct one.
Signed-off-by: Itaru Kitayama kitay...@cl.bb4
In srhink_delalloc(), writeback starts if idle, also check the bdi is
not write congested.
The patch is against the head of the btrfs-next.
Signed-off-by: Itaru Kitayama kitay...@cl.bb4u.ne.jp
fs/btrfs/extent-tree.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs
Resubmit this after the checkpatch test.
In srhink_delalloc(), writeback starts if idle, also check the bdi is
not write congested.
The patch is against the head of the btrfs-next.
Signed-off-by: Itaru Kitayama kitay...@cl.bb4.ne.jp
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
This is the correct one.
Signed-off-by: Itaru Kitayama kitay...@cl.bb4.ne.jp
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index efb044e..c032dbe 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3712,8 +3712,9 @@ static void shrink_delalloc(struct btrfs_root
it and give your Signed-off-by?
Signed-off-by: Itaru Kitayama kitay...@cl.bb4u.ne.jp
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 8862dda..03e5ab3 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2641,7 +2641,7 @@ int extent_readpages(struct extent_io_tree *tree
Hi Miao,
On Sun, 27 Mar 2011 15:00:00 +0800
Miao Xie mi...@cn.fujitsu.com wrote:
I got it. It is because the allocation flag of the metadata's page cache,
which is stored in
the btree inode's i_mapping, was set to be GFP_HIGHUSER_MOVABLE. So if we
allocate pages for
btree's page cache,
Hi Miao,
Chris' stress test, stress.sh -n 50 -c /mnt/linux-2.6 /mnt gave me another
lockdep splat
(see below). I applied your V5 patches on top of the next-rc branch.
I haven't triggered it in my actual testing, but do you think we can iterate a
list of block
groups in an lockless manner
On Wed, 23 Mar 2011 17:47:01 +0800
Miao Xie mi...@cn.fujitsu.com wrote:
we found GFP_KERNEL was passed into kzalloc(), I think this flag trigger the
above lockdep
warning. the attached patch, which against the delayed items operation patch,
may fix this
problem, Could you test it for me?
Hi Miao,
On Tue, 22 Mar 2011 18:03:24 +0800
Miao Xie mi...@cn.fujitsu.com wrote:
The V5 patch is attached, could you test it for me? I have run Chris stress
test, dbench benchmark
on my machine, it work well. I want to check if the above bug still exists or
not.
Thanks
Miao
Here's the
Hi Miao,
The possible circular locking dependency message doesn't show up in the updated
V5. However,
I see a new possible irq lock inversion dependency message while running
xfstests.
=
[ INFO: possible irq lock inversion dependency
On Wed, 23 Mar 2011 12:00:38 +0800
Miao Xie mi...@cn.fujitsu.com wrote:
I is testing the new version, in which I fixed the slab shrinker problem
reported by
Chris. In the new version, the delayed node is removed before the relative
inode is
moved into the unused_inode list(the slab
Hi Miao,
Here is an excerpt of the V4 patch applied kernel boot log:
===
[ INFO: possible circular locking dependency detected ]
2.6.36-xie+ #117
---
vgs/1210 is trying to acquire lock:
On Tue, 22 Mar 2011 11:12:37 +0800
Miao Xie mi...@cn.fujitsu.com wrote:
We can't fix it by this way, because the work threads may do insertion or
deletion at the same time,
and we may lose some directory items.
Ok.
Maybe we can fix it by adding a reference for the delayed directory items,
Hi Miao,
Your updated V4 patch no longer gives me a hang. Thank you.
In the latest V4, btrfs_remove_delayed_node() does just release
a delayed node and returns for most of the time, but for space
cache inodes, it takes trans_mutex and writes the delayed nodes
out to the tree. Is my
Hi Chris,
I have been using that option.
Itaru
On Wed, 16 Mar 2011 13:49:36 -0400
Chris Mason chris.ma...@oracle.com wrote:
Maybe this is related to the free space cache? Is one of you using
mount -o space_cache?
-chris
--
To unsubscribe from this list: send the line unsubscribe
Hi Miao,
My virtual machine hangs upon reboot.
INFO: task umount:1952 blocked for more than 120 seconds.
echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.
umountD fffd44dc 3024 1952 1714 0x
880051ea99e8 0046 8800
Thank you both for your help. I agree that we need to reserve 5 items for that
operation.
Miao's patch (http://marc.info/?l=linux-btrfsm=129802068318176w=2)
fixed this problem, maybe.
Yes, the above patch fixed this problem.
I think this problem is a bug of btrfs_link(), and hope the
Hi Miao,
With the V3 patch applied, I was able to run dbench 50 without a problem.
Thanks,
On Thu, 03 Mar 2011 14:15:44 +0800
Miao Xie mi...@cn.fujitsu.com wrote:
On Thu, 24 Feb 2011 23:02:55 +0900, Itaru Kitayama wrote:
I have applied the V2 patch on top of the next-rc branch of btrfs
Hi Miao,
The V3 patch on top of the next-rc fails to pass an xfstests test 13.
In the btrfs link path, we need to reserve one more metadata in the
trans_block_rsv for the delayed inode update (if needed) to complete.
Here's the log from the test:
[ cut here ]
kernel BUG
Hi Miao,
As you suggested, in btrfs_recover_log_trees(), the items to modify in the
transaction are
not known before entering a tree, we can use the global block reservation for
it.
Signed-off-by: Itaru Kitayama kitay...@cl.bb4u.ne.jp
---
fs/btrfs/tree-log.c |2 ++
1 files changed, 2
is enough reserve metadata to
finish
btrfs_recover_log_trees() without going to ENOSPC. I appreciate your review.
Singed-Off-by: Itaru Kitayama kitay...@cl.bb4u.ne.jp
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 054744a..f26326b 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs
256MB
which is set in __btrfs_alloc_chunk().
Signed-off-by: Itaru Kitayama kitay...@cl.bb4.ne.jp
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 8c26441..54ab490 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3241,6 +3241,8 @@ static int should_alloc_chunk
I've been puzzled why I see a flood of ENOENT returned upon rename during
Fedora 13 and 14's GDM session.
The case is of course handled by your recent patch which is in upstream and
btrfs-unstable, but I thought
doing a log look-up always fail is inefficient so I checked the code path that
.
The patch is for the latest btrfs-unstable tree.
Signed-off-by: Itaru Kitayama kitay...@cl.bb4u.ne.jp
---
fs/btrfs/tree-log.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index a29f193..db63ae4 100644
--- a/fs/btrfs/tree-log.c
+++ b
Thank you, Zhu. Would you send the patch to Andrew or should I pass it on to
him?
Itaru
On Thu, 9 Sep 2010 23:30:52 +0800
Zhu Yanhai zhu.yan...@gmail.com wrote:
Hi,
That's because btrfs_del_dir_entries_in_log() will return the real
errno after Andi's
commit, so btrfs_unlink_inode() has to
;
+ return err;
}
/* see comments for btrfs_del_dir_entries_in_log */
--
Itaru Kitayama kitay...@cl.bb4.ne.jp
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
29 matches
Mail list logo
