On fri, 18 Mar 2011 17:59:04 +0900, Itaru Kitayama wrote:
> 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
Right.
> cache inodes, it tak
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 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
Excerpts from Miao Xie's message of 2011-03-16 10:24:31 -0400:
> On Wed, 16 Mar 2011 18:48:50 +0900, Itaru Kitayama wrote:
> > 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 delay
On Wed, 16 Mar 2011 18:48:50 +0900, Itaru Kitayama wrote:
> 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)?
I think there
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
On Wed, Mar 09, 2011 at 01:40:28PM +0800, Miao Xie wrote:
> Thanks for your advice. But AFAIK, reordering the fields like what you
> said can not reduce the space of delayed_nodes, because a hole is
> placed on the end to make the structure big enough to pack tightly
> into arrays and maintain prop
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,
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
On tue, 8 Mar 2011 17:56:40 +0100, David Sterba wrote:
> Hi,
>
> I did some testing, the speedup results match yours. I was watching kmem cache
> stats of the delayed_node, seem to behave well. Increase and decrease of
> number of active objects, from 3 to about ~400 (creat_unlink 5) and went
Hi,
I did some testing, the speedup results match yours. I was watching kmem cache
stats of the delayed_node, seem to behave well. Increase and decrease of
number of active objects, from 3 to about ~400 (creat_unlink 5) and went
back to initial values after a few seconds. On my setup, there ar
On mon, 07 Mar 2011 08:25:47 +0900, Tsutomu Itoh wrote:
> (2011/03/05 16:01), Itaru Kitayama wrote:
>> 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
(2011/03/05 16:01), Itaru Kitayama wrote:
> 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.
Miao's patch (http://marc.in
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
14 matches
Mail list logo