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
fs/btrfs/extent-tree.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/extent-tree.c b/fs
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
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index efb044e..1aae046
This is the correct one.
Signed-off-by: Itaru Kitayama
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
*root, u64 to_reclaim
re to examine the mechanisms
implemented there are
working as expected.
Thanks,
Itaru
On Mon, Oct 1, 2012 at 7:29 AM, David Sterba wrote:
> Hi again,
>
> On Sun, Sep 30, 2012 at 11:11:10AM +0900, Itaru Kitayama wrote:
>> This is the correct one.
>>
>> Signed-off-by: It
link.
The patch is for the latest btrfs-unstable tree.
Signed-off-by: Itaru Kitayama
---
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/fs/btrfs/
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
s
fault 256MB
which is set in __btrfs_alloc_chunk().
Signed-off-by: Itaru Kitayama
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(struct btrfs
is enough reserve metadata to
finish
btrfs_recover_log_trees() without going to ENOSPC. I appreciate your review.
Singed-Off-by: Itaru Kitayama
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/tree-log.c
@@ -3079,7
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
---
fs/btrfs/tree-log.c |2 ++
1 files changed, 2 insertions(+), 0
Hi Miao,
I have applied the V2 patch on top of the next-rc branch of btrfs-unstable
and ran dbench 50. The run never finished and lots of stall messages recorded
in the log.
Looking at the stack trace, something wrong with the delayed item balancing?
Are you working on the similar problem for V3?
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 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-unstable
&g
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 a
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 fff
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-btrfs&m=129802068318176&w=2)
> > fixed this problem, maybe.
>
> Yes, the above patch fixed this problem.
> I think this problem is a bug of btrfs_link(), and ho
Hi Miao,
The V4 still hangs. Does the new function, btrfs_update_inode_nodelayed() you
introduced to the V4
need take care of a delayed node (commit delayed items of the inode and set the
delayed note to NULL)?
Below is my experimental patch on top of V4 trying to avoid taking trans_mutex
in b
Hi Chris,
I have been using that option.
Itaru
On Wed, 16 Mar 2011 13:49:36 -0400
Chris Mason 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 linux-btrfs" in
the body of
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 understanding
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:
(&dela
On Tue, 22 Mar 2011 11:12:37 +0800
Miao Xie 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, we
> can do rea
Hi Miao,
On Tue, 22 Mar 2011 18:03:24 +0800
Miao Xie 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 boot log (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 detec
On Wed, 23 Mar 2011 12:00:38 +0800
Miao Xie 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 shrinker will reclaim i
On Wed, 23 Mar 2011 17:47:01 +0800
Miao Xie 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?
The possible irq
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 using
Hi Miao,
On Sun, 27 Mar 2011 15:00:00 +0800
Miao Xie 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, this lockdep warni
it and give your Signed-off-by?
Signed-off-by: Itaru Kitayama
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,
prefe
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 p
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 wrote:
> On 10/31/2012 08:13 PM, Itaru Kitayama wrote:
>> Hi LiuBo:
>>
>> I am seeing anoth
Hi Liubo:
The V4 leaves only warnings from btrfs_destroy_inode(). So, you think
it's normal
an "old" extent recorded can be removed from the extent tree by the time
relink_file_extents() invoked?
Itaru
On Thu, Nov 1, 2012 at 8:21 PM, Liu Bo wrote:
> The current btrfs-next HEAD actually have in
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
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/fs/btrfs/tree-log.c
- return 0;
+ return err;
}
/* see comments for btrfs_del_dir_entries_in_log */
--
Itaru Kitayama
--
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-info.html
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 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 check the return
32 matches
Mail list logo
