* ls & flush-btrfs-1 sit at 100% sys
@ 2010-11-18 5:03 Brian Sullivan
2010-11-18 5:15 ` Chris Ball
0 siblings, 1 reply; 12+ messages in thread
From: Brian Sullivan @ 2010-11-18 5:03 UTC (permalink / raw)
To: linux-btrfs
I had been running 2.6.32 for a many months without any issues. Btrfs
on top of a raid6 md array. Filesystem is at 9/11TB used.
I updated to 2.6.34 for a week or so and had no problem.
Updated to 2.6.36 for a few days and no problems.
Update to 2.6.37 and now I cannot read from array.
So I boot up to 2.6.37...
I can run btrfsck and it finds no problems.
I can mount the fs, no problem.
I can run df, no problem.
I can cd to the fs, no problem... even a few folders down, as long as
I can remember exact path because...
Soon as I do 'ls' anywhere it gets stuck.
Is doesn't return, I check top and both ls and flush-btrfs-1 are
sitting at ~50% sys usage each.
I let the system sit in this state all day today while I was at work
(~9 hours) and ls never returned. Even while in this state however,
df still is working. I can still cd to directories (as long as I
recall their exact path).
Not sure what is going on here.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-18 5:03 ls & flush-btrfs-1 sit at 100% sys Brian Sullivan
@ 2010-11-18 5:15 ` Chris Ball
2010-11-18 6:03 ` Brian Sullivan
0 siblings, 1 reply; 12+ messages in thread
From: Chris Ball @ 2010-11-18 5:15 UTC (permalink / raw)
To: Brian Sullivan; +Cc: linux-btrfs
Hi,
> Is doesn't return, I check top and both ls and flush-btrfs-1 are
> sitting at ~50% sys usage each.
Does anything new appear in dmesg when the hang happens? Can you run
alt-sysrq-t (show tasks) and send us the output for the ls process?
- Chris.
--
Chris Ball <cjb@laptop.org>
One Laptop Per Child
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-18 5:15 ` Chris Ball
@ 2010-11-18 6:03 ` Brian Sullivan
2010-11-18 11:08 ` Daniel J Blueman
0 siblings, 1 reply; 12+ messages in thread
From: Brian Sullivan @ 2010-11-18 6:03 UTC (permalink / raw)
To: Chris Ball; +Cc: linux-btrfs
Nothing shows up in dmesg.
[ 8114.870020] ls R running task 0 3438 3375 0x00=
000004
[ 8114.870020] ffff88036339dab8 0000000000000086 ffff88036339da60
ffff88036339dfd8
[ 8114.870020] 00000000000139c0 0000000000000000 ffff88036339dfd8
ffff88036339dfd8
[ 8114.870020] 00000000000139c0 ffff88034f670398 ffff88034f6703a0
ffff88034f670000
[ 8114.870020] Call Trace:
[ 8114.870020] [<ffffffff8159f7b4>] ? schedule+0x224/0x660
[ 8114.870020] [<ffffffff815a01de>] schedule_timeout+0x19e/0x2e0
[ 8114.870020] [<ffffffff81057690>] enqueue_task_fair+0x50/0x60
[ 8114.870020] [<ffffffff8105d550>] enqueue_task+0x70/0xd0
[ 8114.870020] [<ffffffff8105e9be>] ? try_to_wake_up+0x18e/0x3f0
[ 8114.870020] [<ffffffff8105ec20>] ? default_wake_function+0x0/0x20
[ 8114.870020] [<ffffffff815a0196>] ? schedule_timeout+0x156/0x2e0
[ 8114.870020] [<ffffffff81181399>] ? writeback_inodes_sb_nr_if_idle+0=
x49/0x70
[ 8114.870020] [<ffffffffa0e84607>] ? shrink_delalloc+0x127/0x170 [btr=
fs]
[ 8114.870020] [<ffffffffa0e84727>] ? reserve_metadata_bytes+0xd7/0x1f=
0 [btrfs]
[ 8114.870020] [<ffffffffa0e84913>] ? btrfs_block_rsv_add+0x43/0x60 [b=
trfs]
[ 8114.870020] [<ffffffff81085e00>] ? autoremove_wake_function+0x0/0x4=
0
[ 8114.870020] [<ffffffffa0e8498b>] ?
btrfs_trans_reserve_metadata+0x5b/0xa0 [btrfs]
[ 8114.870020] [<ffffffffa0e9a0be>] ? start_transaction+0xbe/0x210 [bt=
rfs]
[ 8114.870020] [<ffffffff8116fa80>] ? filldir+0x0/0xf0
[ 8114.870020] [<ffffffffa0e9a423>] ? btrfs_start_transaction+0x13/0x2=
0 [btrfs]
[ 8114.870020] [<ffffffffa0e9d3e8>] ? btrfs_dirty_inode+0x98/0x120 [bt=
rfs]
[ 8114.870020] [<ffffffff8116fa80>] ? filldir+0x0/0xf0
[ 8114.870020] [<ffffffff81182d9a>] ? __mark_inode_dirty+0x3a/0x200
[ 8114.870020] [<ffffffff811754f4>] ? touch_atime+0xf4/0x100
[ 8114.870020] [<ffffffff8116f92c>] ? vfs_readdir+0xcc/0xd0
[ 8114.870020] [<ffffffff8116f9ba>] ? sys_getdents+0x8a/0xe0
[ 8114.870020] [<ffffffff815a2515>] ? page_fault+0x25/0x30
[ 8114.870020] [<ffffffff8100c132>] ? system_call_fastpath+0x16/0x1b
[ 8114.870020] flush-btrfs-1 R running task 0 3439 2 0x00=
000000
[ 8114.870020] ffff8803631c5e60 0000000000000046 ffff8803631c5e00
0000000000000000
[ 8114.870020] ffff8803631c5e20 00000000000139c0 ffff8803631c5fd8
ffff8803631c5fd8
[ 8114.870020] 00000000000139c0 ffff8803507fd9b0 ffff8803631c5e60
ffff880362205b00
[ 8114.870020] Call Trace:
[ 8114.870020] [<ffffffff81182b00>] ? bdi_writeback_thread+0x0/0x260
[ 8114.870020] [<ffffffff81182bb3>] bdi_writeback_thread+0xb3/0x260
[ 8114.870020] [<ffffffff81182b00>] ? bdi_writeback_thread+0x0/0x260
[ 8114.870020] [<ffffffff81085727>] kthread+0x97/0xa0
[ 8114.870020] [<ffffffff8100cf24>] kernel_thread_helper+0x4/0x10
[ 8114.870020] [<ffffffff81085690>] ? kthread+0x0/0xa0
[ 8114.870020] [<ffffffff8100cf20>] ? kernel_thread_helper+0x0/0x10
On Wed, Nov 17, 2010 at 9:15 PM, Chris Ball <cjb@laptop.org> wrote:
> Hi,
>
> =A0 > Is doesn't return, I check top and both ls and flush-btrfs-1 ar=
e
> =A0 > sitting at ~50% sys usage each.
>
> Does anything new appear in dmesg when the hang happens? =A0Can you r=
un
> alt-sysrq-t (show tasks) and send us the output for the ls process?
>
> - Chris.
> --
> Chris Ball =A0 <cjb@laptop.org>
> One Laptop Per Child
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-18 6:03 ` Brian Sullivan
@ 2010-11-18 11:08 ` Daniel J Blueman
2010-11-18 18:30 ` Brian Sullivan
0 siblings, 1 reply; 12+ messages in thread
From: Daniel J Blueman @ 2010-11-18 11:08 UTC (permalink / raw)
To: Brian Sullivan; +Cc: Chris Ball, linux-btrfs
On 18 November 2010 06:03, Brian Sullivan <bexamous@gmail.com> wrote:
> Nothing shows up in dmesg.
>
> [ 8114.870020] ls =A0 =A0 =A0 =A0 =A0 =A0R =A0running task =A0 =A0 =A0=
=A00 =A03438 =A0 3375 0x00000004
> [ 8114.870020] =A0ffff88036339dab8 0000000000000086 ffff88036339da60
> ffff88036339dfd8
> [ 8114.870020] =A000000000000139c0 0000000000000000 ffff88036339dfd8
> ffff88036339dfd8
> [ 8114.870020] =A000000000000139c0 ffff88034f670398 ffff88034f6703a0
> ffff88034f670000
> [ 8114.870020] Call Trace:
> [ 8114.870020] =A0[<ffffffff8159f7b4>] ? schedule+0x224/0x660
> [ 8114.870020] =A0[<ffffffff815a01de>] schedule_timeout+0x19e/0x2e0
> [ 8114.870020] =A0[<ffffffff81057690>] enqueue_task_fair+0x50/0x60
> [ 8114.870020] =A0[<ffffffff8105d550>] enqueue_task+0x70/0xd0
> [ 8114.870020] =A0[<ffffffff8105e9be>] ? try_to_wake_up+0x18e/0x3f0
> [ 8114.870020] =A0[<ffffffff8105ec20>] ? default_wake_function+0x0/0x=
20
> [ 8114.870020] =A0[<ffffffff815a0196>] ? schedule_timeout+0x156/0x2e0
> [ 8114.870020] =A0[<ffffffff81181399>] ? writeback_inodes_sb_nr_if_id=
le+0x49/0x70
> [ 8114.870020] =A0[<ffffffffa0e84607>] ? shrink_delalloc+0x127/0x170 =
[btrfs]
> [ 8114.870020] =A0[<ffffffffa0e84727>] ? reserve_metadata_bytes+0xd7/=
0x1f0 [btrfs]
> [ 8114.870020] =A0[<ffffffffa0e84913>] ? btrfs_block_rsv_add+0x43/0x6=
0 [btrfs]
> [ 8114.870020] =A0[<ffffffff81085e00>] ? autoremove_wake_function+0x0=
/0x40
> [ 8114.870020] =A0[<ffffffffa0e8498b>] ?
> btrfs_trans_reserve_metadata+0x5b/0xa0 [btrfs]
> [ 8114.870020] =A0[<ffffffffa0e9a0be>] ? start_transaction+0xbe/0x210=
[btrfs]
> [ 8114.870020] =A0[<ffffffff8116fa80>] ? filldir+0x0/0xf0
> [ 8114.870020] =A0[<ffffffffa0e9a423>] ? btrfs_start_transaction+0x13=
/0x20 [btrfs]
> [ 8114.870020] =A0[<ffffffffa0e9d3e8>] ? btrfs_dirty_inode+0x98/0x120=
[btrfs]
> [ 8114.870020] =A0[<ffffffff8116fa80>] ? filldir+0x0/0xf0
> [ 8114.870020] =A0[<ffffffff81182d9a>] ? __mark_inode_dirty+0x3a/0x20=
0
> [ 8114.870020] =A0[<ffffffff811754f4>] ? touch_atime+0xf4/0x100
> [ 8114.870020] =A0[<ffffffff8116f92c>] ? vfs_readdir+0xcc/0xd0
> [ 8114.870020] =A0[<ffffffff8116f9ba>] ? sys_getdents+0x8a/0xe0
> [ 8114.870020] =A0[<ffffffff815a2515>] ? page_fault+0x25/0x30
> [ 8114.870020] =A0[<ffffffff8100c132>] ? system_call_fastpath+0x16/0x=
1b
> [ 8114.870020] flush-btrfs-1 R =A0running task =A0 =A0 =A0 =A00 =A034=
39 =A0 =A0 =A02 0x00000000
> [ 8114.870020] =A0ffff8803631c5e60 0000000000000046 ffff8803631c5e00
> 0000000000000000
> [ 8114.870020] =A0ffff8803631c5e20 00000000000139c0 ffff8803631c5fd8
> ffff8803631c5fd8
> [ 8114.870020] =A000000000000139c0 ffff8803507fd9b0 ffff8803631c5e60
> ffff880362205b00
> [ 8114.870020] Call Trace:
> [ 8114.870020] =A0[<ffffffff81182b00>] ? bdi_writeback_thread+0x0/0x2=
60
> [ 8114.870020] =A0[<ffffffff81182bb3>] bdi_writeback_thread+0xb3/0x26=
0
> [ 8114.870020] =A0[<ffffffff81182b00>] ? bdi_writeback_thread+0x0/0x2=
60
> [ 8114.870020] =A0[<ffffffff81085727>] kthread+0x97/0xa0
> [ 8114.870020] =A0[<ffffffff8100cf24>] kernel_thread_helper+0x4/0x10
> [ 8114.870020] =A0[<ffffffff81085690>] ? kthread+0x0/0xa0
> [ 8114.870020] =A0[<ffffffff8100cf20>] ? kernel_thread_helper+0x0/0x1=
0
Interesting. If you mount the filesystem with 'noatime,nodiratime' or
'ro', does it allow ls to return?
Daniel
--=20
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-18 11:08 ` Daniel J Blueman
@ 2010-11-18 18:30 ` Brian Sullivan
2010-11-19 14:32 ` Chris Mason
0 siblings, 1 reply; 12+ messages in thread
From: Brian Sullivan @ 2010-11-18 18:30 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: Chris Ball, linux-btrfs
Yep actually, with noatime,nodiratime ls is fine. I didn't try ro but
I assume that'll work too. So with noatime,nodiratime I can go around
in tree and ls works. If I try to touch a new file, touch doesn't
return. If I then ls in that same folder ls doesn't return either.
So yeah seems like soon as something has to write.
Also after I run touch, it doesn't return, I look at top, nothing is
spinning, everything is at 0% usage. After a minute or so then touch
and flush-btrfs-1 jump to 50%sys each and sit there.
Think this was just before they went to 50% usage and were still sittin=
g at 0:
[ 420.110021] touch S ffff8803646c9a58 0 3337 3252 0x00=
000000
[ 420.110021] ffff8803416c9a28 0000000000000086 0000000000000000
ffff8803416c9fd8
[ 420.110021] 00000000000139c0 00000000000139c0 ffff8803416c9fd8
ffff8803416c9fd8
[ 420.110021] 00000000000139c0 ffff8803646c9a58 ffff8803646c9a60
ffff8803646c96c0
[ 420.110021] Call Trace:
[ 420.110021] [<ffffffff815a0196>] schedule_timeout+0x156/0x2e0
[ 420.110021] [<ffffffff810733b0>] ? process_timeout+0x0/0x10
[ 420.110021] [<ffffffffa0dbe607>] shrink_delalloc+0x127/0x170 [btrfs=
]
[ 420.110021] [<ffffffffa0dbe727>] reserve_metadata_bytes+0xd7/0x1f0 =
[btrfs]
[ 420.110021] [<ffffffffa0dbe913>] btrfs_block_rsv_add+0x43/0x60 [btr=
fs]
[ 420.110021] [<ffffffffa0dbe98b>]
btrfs_trans_reserve_metadata+0x5b/0xa0 [btrfs]
[ 420.110021] [<ffffffffa0dd40be>] start_transaction+0xbe/0x210 [btrf=
s]
[ 420.110021] [<ffffffffa0dd4423>] btrfs_start_transaction+0x13/0x20 =
[btrfs]
[ 420.110021] [<ffffffffa0dda8a4>] btrfs_create+0x84/0x220 [btrfs]
[ 420.110021] [<ffffffff81168c94>] ? generic_permission+0x24/0xc0
[ 420.110021] [<ffffffff8116a7a8>] vfs_create+0xb8/0x110
[ 420.110021] [<ffffffff8116a870>] __open_namei_create+0x70/0x100
[ 420.110021] [<ffffffff8116b366>] do_last+0x486/0x4e0
[ 420.110021] [<ffffffff8116c27e>] do_filp_open+0x25e/0x620
[ 420.110021] [<ffffffff812d5e37>] ? __strncpy_from_user+0x27/0x60
[ 420.110021] [<ffffffff815a1bde>] ? _raw_spin_lock+0xe/0x20
[ 420.110021] [<ffffffff811786e6>] ? alloc_fd+0x116/0x140
[ 420.110021] [<ffffffff8115caaa>] do_sys_open+0x6a/0x110
[ 420.110021] [<ffffffff8115cb90>] sys_open+0x20/0x30
[ 420.110021] [<ffffffff8100c132>] system_call_fastpath+0x16/0x1b
[ 420.110021] ls D ffff8803655347d8 0 3355 3270 0x00=
000004
[ 420.110021] ffff880362b47e58 0000000000000086 ffff880362b47e38
ffff880362b47fd8
[ 420.110021] 00000000000139c0 00000000000139c0 ffff880362b47fd8
ffff880362b47fd8
[ 420.110021] 00000000000139c0 ffff8803655347d8 ffff8803655347e0
ffff880365534440
[ 420.110021] Call Trace:
[ 420.110021] [<ffffffff815a0849>] __mutex_lock_killable_slowpath+0xf=
9/0x1b0
[ 420.110021] [<ffffffff8116fa80>] ? filldir+0x0/0xf0
[ 420.110021] [<ffffffff815a0948>] mutex_lock_killable+0x48/0x60
[ 420.110021] [<ffffffff8116f8e2>] vfs_readdir+0x82/0xd0
[ 420.110021] [<ffffffff8116f9ba>] sys_getdents+0x8a/0xe0
[ 420.110021] [<ffffffff815a2515>] ? page_fault+0x25/0x30
[ 420.110021] [<ffffffff8100c132>] system_call_fastpath+0x16/0x1b
On Thu, Nov 18, 2010 at 3:08 AM, Daniel J Blueman
<daniel.blueman@gmail.com> wrote:
> On 18 November 2010 06:03, Brian Sullivan <bexamous@gmail.com> wrote:
>> Nothing shows up in dmesg.
>>
>> [ 8114.870020] ls =A0 =A0 =A0 =A0 =A0 =A0R =A0running task =A0 =A0 =A0=
=A00 =A03438 =A0 3375 0x00000004
>> [ 8114.870020] =A0ffff88036339dab8 0000000000000086 ffff88036339da60
>> ffff88036339dfd8
>> [ 8114.870020] =A000000000000139c0 0000000000000000 ffff88036339dfd8
>> ffff88036339dfd8
>> [ 8114.870020] =A000000000000139c0 ffff88034f670398 ffff88034f6703a0
>> ffff88034f670000
>> [ 8114.870020] Call Trace:
>> [ 8114.870020] =A0[<ffffffff8159f7b4>] ? schedule+0x224/0x660
>> [ 8114.870020] =A0[<ffffffff815a01de>] schedule_timeout+0x19e/0x2e0
>> [ 8114.870020] =A0[<ffffffff81057690>] enqueue_task_fair+0x50/0x60
>> [ 8114.870020] =A0[<ffffffff8105d550>] enqueue_task+0x70/0xd0
>> [ 8114.870020] =A0[<ffffffff8105e9be>] ? try_to_wake_up+0x18e/0x3f0
>> [ 8114.870020] =A0[<ffffffff8105ec20>] ? default_wake_function+0x0/0=
x20
>> [ 8114.870020] =A0[<ffffffff815a0196>] ? schedule_timeout+0x156/0x2e=
0
>> [ 8114.870020] =A0[<ffffffff81181399>] ? writeback_inodes_sb_nr_if_i=
dle+0x49/0x70
>> [ 8114.870020] =A0[<ffffffffa0e84607>] ? shrink_delalloc+0x127/0x170=
[btrfs]
>> [ 8114.870020] =A0[<ffffffffa0e84727>] ? reserve_metadata_bytes+0xd7=
/0x1f0 [btrfs]
>> [ 8114.870020] =A0[<ffffffffa0e84913>] ? btrfs_block_rsv_add+0x43/0x=
60 [btrfs]
>> [ 8114.870020] =A0[<ffffffff81085e00>] ? autoremove_wake_function+0x=
0/0x40
>> [ 8114.870020] =A0[<ffffffffa0e8498b>] ?
>> btrfs_trans_reserve_metadata+0x5b/0xa0 [btrfs]
>> [ 8114.870020] =A0[<ffffffffa0e9a0be>] ? start_transaction+0xbe/0x21=
0 [btrfs]
>> [ 8114.870020] =A0[<ffffffff8116fa80>] ? filldir+0x0/0xf0
>> [ 8114.870020] =A0[<ffffffffa0e9a423>] ? btrfs_start_transaction+0x1=
3/0x20 [btrfs]
>> [ 8114.870020] =A0[<ffffffffa0e9d3e8>] ? btrfs_dirty_inode+0x98/0x12=
0 [btrfs]
>> [ 8114.870020] =A0[<ffffffff8116fa80>] ? filldir+0x0/0xf0
>> [ 8114.870020] =A0[<ffffffff81182d9a>] ? __mark_inode_dirty+0x3a/0x2=
00
>> [ 8114.870020] =A0[<ffffffff811754f4>] ? touch_atime+0xf4/0x100
>> [ 8114.870020] =A0[<ffffffff8116f92c>] ? vfs_readdir+0xcc/0xd0
>> [ 8114.870020] =A0[<ffffffff8116f9ba>] ? sys_getdents+0x8a/0xe0
>> [ 8114.870020] =A0[<ffffffff815a2515>] ? page_fault+0x25/0x30
>> [ 8114.870020] =A0[<ffffffff8100c132>] ? system_call_fastpath+0x16/0=
x1b
>> [ 8114.870020] flush-btrfs-1 R =A0running task =A0 =A0 =A0 =A00 =A03=
439 =A0 =A0 =A02 0x00000000
>> [ 8114.870020] =A0ffff8803631c5e60 0000000000000046 ffff8803631c5e00
>> 0000000000000000
>> [ 8114.870020] =A0ffff8803631c5e20 00000000000139c0 ffff8803631c5fd8
>> ffff8803631c5fd8
>> [ 8114.870020] =A000000000000139c0 ffff8803507fd9b0 ffff8803631c5e60
>> ffff880362205b00
>> [ 8114.870020] Call Trace:
>> [ 8114.870020] =A0[<ffffffff81182b00>] ? bdi_writeback_thread+0x0/0x=
260
>> [ 8114.870020] =A0[<ffffffff81182bb3>] bdi_writeback_thread+0xb3/0x2=
60
>> [ 8114.870020] =A0[<ffffffff81182b00>] ? bdi_writeback_thread+0x0/0x=
260
>> [ 8114.870020] =A0[<ffffffff81085727>] kthread+0x97/0xa0
>> [ 8114.870020] =A0[<ffffffff8100cf24>] kernel_thread_helper+0x4/0x10
>> [ 8114.870020] =A0[<ffffffff81085690>] ? kthread+0x0/0xa0
>> [ 8114.870020] =A0[<ffffffff8100cf20>] ? kernel_thread_helper+0x0/0x=
10
>
> Interesting. If you mount the filesystem with 'noatime,nodiratime' or
> 'ro', does it allow ls to return?
>
> Daniel
> --
> Daniel J Blueman
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-18 18:30 ` Brian Sullivan
@ 2010-11-19 14:32 ` Chris Mason
2010-11-19 14:46 ` Josef Bacik
0 siblings, 1 reply; 12+ messages in thread
From: Chris Mason @ 2010-11-19 14:32 UTC (permalink / raw)
To: Brian Sullivan; +Cc: Daniel J Blueman, Chris Ball, linux-btrfs
Excerpts from Brian Sullivan's message of 2010-11-18 13:30:51 -0500:
> Yep actually, with noatime,nodiratime ls is fine. I didn't try ro but
> I assume that'll work too. So with noatime,nodiratime I can go around
> in tree and ls works. If I try to touch a new file, touch doesn't
> return. If I then ls in that same folder ls doesn't return either.
> So yeah seems like soon as something has to write.
>
> Also after I run touch, it doesn't return, I look at top, nothing is
> spinning, everything is at 0% usage. After a minute or so then touch
> and flush-btrfs-1 jump to 50%sys each and sit there.
So, based on this trace we're banging on the delalloc flushing to free
up room.
I just wanted to confirm, you're seeing this with 2.6.37-rc? I thought
I had fixed up this delalloc hammering.
-chris
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-19 14:32 ` Chris Mason
@ 2010-11-19 14:46 ` Josef Bacik
2010-11-19 20:09 ` Brian Sullivan
0 siblings, 1 reply; 12+ messages in thread
From: Josef Bacik @ 2010-11-19 14:46 UTC (permalink / raw)
To: Chris Mason; +Cc: Brian Sullivan, Daniel J Blueman, Chris Ball, linux-btrfs
On Fri, Nov 19, 2010 at 09:32:46AM -0500, Chris Mason wrote:
> Excerpts from Brian Sullivan's message of 2010-11-18 13:30:51 -0500:
> > Yep actually, with noatime,nodiratime ls is fine. I didn't try ro but
> > I assume that'll work too. So with noatime,nodiratime I can go around
> > in tree and ls works. If I try to touch a new file, touch doesn't
> > return. If I then ls in that same folder ls doesn't return either.
> > So yeah seems like soon as something has to write.
> >
> > Also after I run touch, it doesn't return, I look at top, nothing is
> > spinning, everything is at 0% usage. After a minute or so then touch
> > and flush-btrfs-1 jump to 50%sys each and sit there.
>
> So, based on this trace we're banging on the delalloc flushing to free
> up room.
>
> I just wanted to confirm, you're seeing this with 2.6.37-rc? I thought
> I had fixed up this delalloc hammering.
>
Also can you run with this patch
http://www.spinics.net/lists/linux-btrfs/msg06890.html
its a crap bug which will make us look like we're out of space when we arent and
we'll flush alot more. Thanks,
Josef
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-19 14:46 ` Josef Bacik
@ 2010-11-19 20:09 ` Brian Sullivan
2010-11-22 23:29 ` Brian Sullivan
0 siblings, 1 reply; 12+ messages in thread
From: Brian Sullivan @ 2010-11-19 20:09 UTC (permalink / raw)
To: Josef Bacik; +Cc: Chris Mason, Daniel J Blueman, Chris Ball, linux-btrfs
On Fri, Nov 19, 2010 at 6:46 AM, Josef Bacik <josef@redhat.com> wrote:
> On Fri, Nov 19, 2010 at 09:32:46AM -0500, Chris Mason wrote:
>>
>> I just wanted to confirm, you're seeing this with 2.6.37-rc? =A0I th=
ought
>> I had fixed up this delalloc hammering.
>>
I installed 2.6.37-rc2 from an Ubuntu PPA.
>
> Also can you run with this patch
>
> http://www.spinics.net/lists/linux-btrfs/msg06890.html
>
Will try tonight.
-Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-19 20:09 ` Brian Sullivan
@ 2010-11-22 23:29 ` Brian Sullivan
2010-11-23 0:54 ` Chris Mason
0 siblings, 1 reply; 12+ messages in thread
From: Brian Sullivan @ 2010-11-22 23:29 UTC (permalink / raw)
To: Josef Bacik; +Cc: Chris Mason, Daniel J Blueman, Chris Ball, linux-btrfs
On Fri, Nov 19, 2010 at 12:09 PM, Brian Sullivan <bexamous@gmail.com> w=
rote:
> On Fri, Nov 19, 2010 at 6:46 AM, Josef Bacik <josef@redhat.com> wrote=
:
>> On Fri, Nov 19, 2010 at 09:32:46AM -0500, Chris Mason wrote:
>>>
>>> I just wanted to confirm, you're seeing this with 2.6.37-rc? =A0I t=
hought
>>> I had fixed up this delalloc hammering.
>>>
>
> I installed 2.6.37-rc2 from an Ubuntu PPA.
>
>>
>> Also can you run with this patch
>>
>> http://www.spinics.net/lists/linux-btrfs/msg06890.html
>>
>
> Will try tonight.
>
Got 2.6.37-rc2 from kernel.org, applied this patch, and still not able
to write to the filesystem.
I hooked up another array (md raid w/btfs on top) and it this one
works fine. Should I just wipe out of the broken fs and recreate it?
Or is there anything else I should try?
-Brian
> -Brian
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-22 23:29 ` Brian Sullivan
@ 2010-11-23 0:54 ` Chris Mason
2010-11-23 20:27 ` Brian Sullivan
0 siblings, 1 reply; 12+ messages in thread
From: Chris Mason @ 2010-11-23 0:54 UTC (permalink / raw)
To: Brian Sullivan; +Cc: Josef Bacik, Daniel J Blueman, Chris Ball, linux-btrfs
Excerpts from Brian Sullivan's message of 2010-11-22 18:29:42 -0500:
> On Fri, Nov 19, 2010 at 12:09 PM, Brian Sullivan <bexamous@gmail.com>=
wrote:
> > On Fri, Nov 19, 2010 at 6:46 AM, Josef Bacik <josef@redhat.com> wro=
te:
> >> On Fri, Nov 19, 2010 at 09:32:46AM -0500, Chris Mason wrote:
> >>>
> >>> I just wanted to confirm, you're seeing this with 2.6.37-rc? =C2=A0=
I thought
> >>> I had fixed up this delalloc hammering.
> >>>
> >
> > I installed 2.6.37-rc2 from an Ubuntu PPA.
> >
> >>
> >> Also can you run with this patch
> >>
> >> http://www.spinics.net/lists/linux-btrfs/msg06890.html
> >>
> >
> > Will try tonight.
> >
>=20
> Got 2.6.37-rc2 from kernel.org, applied this patch, and still not abl=
e
> to write to the filesystem.
So with the patch are you still seeing the 100% system time?
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-23 0:54 ` Chris Mason
@ 2010-11-23 20:27 ` Brian Sullivan
2010-11-23 21:07 ` Chris Mason
0 siblings, 1 reply; 12+ messages in thread
From: Brian Sullivan @ 2010-11-23 20:27 UTC (permalink / raw)
To: Chris Mason; +Cc: Josef Bacik, Daniel J Blueman, Chris Ball, linux-btrfs
On Mon, Nov 22, 2010 at 4:54 PM, Chris Mason <chris.mason@oracle.com> w=
rote:
> Excerpts from Brian Sullivan's message of 2010-11-22 18:29:42 -0500:
>> On Fri, Nov 19, 2010 at 12:09 PM, Brian Sullivan <bexamous@gmail.com=
> wrote:
>> > On Fri, Nov 19, 2010 at 6:46 AM, Josef Bacik <josef@redhat.com> wr=
ote:
>> >> On Fri, Nov 19, 2010 at 09:32:46AM -0500, Chris Mason wrote:
>> >>>
>> >>> I just wanted to confirm, you're seeing this with 2.6.37-rc? =A0=
I thought
>> >>> I had fixed up this delalloc hammering.
>> >>>
>> >
>> > I installed 2.6.37-rc2 from an Ubuntu PPA.
>> >
>> >>
>> >> Also can you run with this patch
>> >>
>> >> http://www.spinics.net/lists/linux-btrfs/msg06890.html
>> >>
>> >
>> > Will try tonight.
>> >
>>
>> Got 2.6.37-rc2 from kernel.org, applied this patch, and still not ab=
le
>> to write to the filesystem.
>
> So with the patch are you still seeing the 100% system time?
>
> -chris
>
Yes, no change with patch.
-Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ls & flush-btrfs-1 sit at 100% sys
2010-11-23 20:27 ` Brian Sullivan
@ 2010-11-23 21:07 ` Chris Mason
0 siblings, 0 replies; 12+ messages in thread
From: Chris Mason @ 2010-11-23 21:07 UTC (permalink / raw)
To: Brian Sullivan; +Cc: Josef Bacik, Daniel J Blueman, Chris Ball, linux-btrfs
Excerpts from Brian Sullivan's message of 2010-11-23 15:27:09 -0500:
> On Mon, Nov 22, 2010 at 4:54 PM, Chris Mason <chris.mason@oracle.com>=
wrote:
> > Excerpts from Brian Sullivan's message of 2010-11-22 18:29:42 -0500=
:
> >> On Fri, Nov 19, 2010 at 12:09 PM, Brian Sullivan <bexamous@gmail.c=
om> wrote:
> >> > On Fri, Nov 19, 2010 at 6:46 AM, Josef Bacik <josef@redhat.com> =
wrote:
> >> >> On Fri, Nov 19, 2010 at 09:32:46AM -0500, Chris Mason wrote:
> >> >>>
> >> >>> I just wanted to confirm, you're seeing this with 2.6.37-rc? =C2=
=A0I thought
> >> >>> I had fixed up this delalloc hammering.
> >> >>>
> >> >
> >> > I installed 2.6.37-rc2 from an Ubuntu PPA.
> >> >
> >> >>
> >> >> Also can you run with this patch
> >> >>
> >> >> http://www.spinics.net/lists/linux-btrfs/msg06890.html
> >> >>
> >> >
> >> > Will try tonight.
> >> >
> >>
> >> Got 2.6.37-rc2 from kernel.org, applied this patch, and still not =
able
> >> to write to the filesystem.
> >
> > So with the patch are you still seeing the 100% system time?
> >
> > -chris
> >
>=20
> Yes, no change with patch.
Ok, the short term solution is going to be adding another drive to your
=46S and letting the space spill over to there.
I'd like to try and reproduce here though, if it isn't too difficult to
keep things in the current state?
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-11-23 21:07 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-18 5:03 ls & flush-btrfs-1 sit at 100% sys Brian Sullivan
2010-11-18 5:15 ` Chris Ball
2010-11-18 6:03 ` Brian Sullivan
2010-11-18 11:08 ` Daniel J Blueman
2010-11-18 18:30 ` Brian Sullivan
2010-11-19 14:32 ` Chris Mason
2010-11-19 14:46 ` Josef Bacik
2010-11-19 20:09 ` Brian Sullivan
2010-11-22 23:29 ` Brian Sullivan
2010-11-23 0:54 ` Chris Mason
2010-11-23 20:27 ` Brian Sullivan
2010-11-23 21:07 ` Chris Mason
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.