[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#632475: btrfs flushing hangs



On Sat, 2011-07-02 at 16:26 +0000, Clint Adams wrote:
> Package: linux-2.6
> Version: 2.6.39-2
> 
> This btrfs filesystem seemed to work flawlessly under
> linux-image-2.6.32-5-kirkwood, but now with
> linux-image-2.6.39-2-kirkwood, things like this
> happen:
> 
> 
> [ 4852.113592] device fsid 1b48baae86d0b237-51ab536c499a6594 devid 1 transid 163957 /dev/sda1
> [ 5288.244963] INFO: task btrfs-transacti:2232 blocked for more than 120 seconds.
> [ 5288.252250] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 5288.260132] btrfs-transacti D c02e3e4c     0  2232      2 0x00000000
> [ 5288.266549] [<c02e3e4c>] (schedule+0x4ac/0x510) from [<c02e43b8>] (schedule_timeout+0x1c/0x230)
> [ 5288.275492] [<c02e43b8>] (schedule_timeout+0x1c/0x230) from [<bf0df564>] (btrfs_commit_transaction+0x2dc/0x6ec [btrfs])
> [ 5288.286568] [<bf0df564>] (btrfs_commit_transaction+0x2dc/0x6ec [btrfs]) from [<bf0d9df8>] (transaction_kthread+0x12c/0x200 [btrfs])
> [ 5288.298586] [<bf0d9df8>] (transaction_kthread+0x12c/0x200 [btrfs]) from [<c006177c>] (kthread+0x84/0x8c)
> [ 5288.308149] [<c006177c>] (kthread+0x84/0x8c) from [<c00315b0>] (kernel_thread_exit+0x0/0x8)
[...]
> Eventually the box seems to freeze entirely and need to be powercycled.

> This problem does not seem to occur when there is plenty
> of free space.
> 
> It makes it impossible to fill the partition any more
> than this:
> 
> /dev/sda1             1.4T  1.3T  1.8G 100%

This change in 3.0-rc2 *might* be dealing with the same issue:

commit d82a6f1d7e8b61ed5996334d0db66651bb43641d
Author: Josef Bacik <josef@redhat.com>
Date:   Wed May 11 15:26:06 2011 -0400

    Btrfs: kill BTRFS_I(inode)->block_group
    
    Originally this was going to be used as a way to give hints to the allocator,
    but frankly we can get much better hints elsewhere and it's not even used at all
    for anything usefull.  In addition to be completely useless, when we initialize
    an inode we try and find a freeish block group to set as the inodes block group,
    and with a completely full 40gb fs this takes _forever_, so I imagine with say
    1tb fs this is just unbearable.  So just axe the thing altoghether, we don't
    need it and it saves us 8 bytes in the inode and saves us 500 microseconds per
    inode lookup in my testcase.  Thanks,
    
    Signed-off-by: Josef Bacik <josef@redhat.com>

Could you test 3.0-rc5 from experimental, please?

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: