* Re: btrfs lockup after mounting for a second time on 2.6.26
2009-02-12 14:51 ` Chris Mason
@ 2009-02-12 16:57 ` Lee Trager
2009-02-12 17:08 ` Lee Trager
2009-02-18 20:51 ` Lee Trager
2 siblings, 0 replies; 5+ messages in thread
From: Lee Trager @ 2009-02-12 16:57 UTC (permalink / raw)
To: Chris Mason; +Cc: Lee Trager, Btrfs Development List
Ok here it is
[ 227.637684] SysRq : Show Blocked State
[ 227.639369] task PC stack pid father
[ 227.639369] ls D f784b9d4 0 3101 3003
[ 227.639369] f74e4da0 00000082 0000d950 f784b9d4 0000d950 f74e4f2c c1815fa0 00000001
[ 227.639369] f784b9cc ffff9728 c18031b4 c013604c 00000000 00000000 00000000 000000ff
[ 227.639369] c1815fa0 0145b000 c18031b4 c015688a c02b8498 f3459bb4 f3459bb4 c01568bd
[ 227.639369] Call Trace:
[ 227.639369] [<c013604c>] getnstimeofday+0x37/0xbc
[ 227.639369] [<c015688a>] sync_page+0x0/0x36
[ 227.639369] [<c02b8498>] io_schedule+0x49/0x80
[ 227.639369] [<c01568bd>] sync_page+0x33/0x36
[ 227.639369] [<c02b85c4>] __wait_on_bit_lock+0x2a/0x52
[ 227.639369] [<c015687c>] __lock_page+0x4e/0x54
[ 227.639369] [<c0131909>] wake_bit_function+0x0/0x3c
[ 227.639369] [<f8ce8312>] read_extent_buffer_pages+0x133/0x2f1 [btrfs]
[ 227.639369] [<c0117b50>] kmap_atomic_prot+0x9d/0xcc
[ 227.639369] [<f8ccd550>] btree_read_extent_buffer_pages+0x39/0x8c [btrfs]
[ 227.639369] [<f8ccf219>] btree_get_extent+0x0/0x173 [btrfs]
[ 227.639369] [<f8ccd856>] read_tree_block+0x29/0x4c [btrfs]
[ 227.639369] [<f8cb9c4a>] read_node_slot+0xa4/0xb2 [btrfs]
[ 227.639369] [<f8cbe46f>] btrfs_next_leaf+0x16f/0x27d [btrfs]
[ 227.639369] [<f8cc080a>] cache_block_group+0xe9/0x2a0 [btrfs]
[ 227.639369] [<c0184354>] alloc_inode+0x12e/0x186
[ 227.639369] [<f8cc1554>] find_free_extent+0x32a/0x7b2 [btrfs]
[ 227.639369] [<f8cc1bb1>] __btrfs_reserve_extent+0x1d5/0x370 [btrfs]
[ 227.639369] [<f8cc1d8b>] btrfs_reserve_extent+0x3f/0x61 [btrfs]
[ 227.639369] [<f8cbddbb>] btrfs_search_slot+0x257/0x79c [btrfs]
[ 227.639369] [<c0117c79>] kunmap_atomic+0x67/0x8a
[ 227.639369] [<f8ccccff>] btrfs_lookup_inode+0x27/0x88 [btrfs]
[ 227.639369] [<f8cd56c0>] btrfs_update_inode+0x3d/0xae [btrfs]
[ 227.639369] [<f8cd64e4>] btrfs_dirty_inode+0x3d/0x4a [btrfs]
[ 227.639369] [<c018cc33>] __mark_inode_dirty+0x21/0x12a
[ 227.639369] [<c0184f0a>] touch_atime+0xc7/0xd1
[ 227.639369] [<c017e8df>] vfs_readdir+0x75/0x8c
[ 227.639369] [<c017e6ec>] filldir64+0x0/0xc5
[ 227.639369] [<c017e959>] sys_getdents64+0x63/0xa5
[ 227.639369] [<c0103853>] sysenter_past_esp+0x78/0xb1
[ 227.639369] =======================
[ 227.639369] Sched Debug Version: v0.07, 2.6.26-1-686 #1
[ 227.639369] now at 210726.291061 msecs
[ 227.639369] .sysctl_sched_latency : 40.000000
[ 227.639369] .sysctl_sched_min_granularity : 8.000000
[ 227.639369] .sysctl_sched_wakeup_granularity : 20.000000
[ 227.639369] .sysctl_sched_child_runs_first : 0.000001
[ 227.639369] .sysctl_sched_features : 895
[ 227.639369]
[ 227.639369] cpu#0, 2200.225 MHz
[ 227.639369] .nr_running : 2
[ 227.639369] .load : 2048
[ 227.639369] .nr_switches : 34074
On Thu, Feb 12, 2009 at 09:51:12AM -0500, Chris Mason wrote:
> On Thu, 2009-02-12 at 01:31 -0500, Lee Trager wrote:
> > While running a few tests with the btrfs sources pulled from
> > btrfs-unstable patched with my patch to compile under 2.6.26 I
> > encountered a very weird problem. Everything works fine the first time I
> > mount the file system (either actual disk or loop back). When I
> > unmounted the file system and mounted it again(I'm not doing mount -o
> > remount ...) btrfs is completely unusable. When I tried to view some of
> > the data which I previously put on the btrfs partition by doing a simple
> > ls /mnt/btrfs in bash nothing happens. ls shows nothing, just hangs, and
> > I am unable to kill ls. The same thing happens when I try to copy a file
> > from my ext3 partition onto the btrfs partition after mounting it for a
> > second time. The rest of the system is completely usable and the only
> > things that are effects are applications which are trying to read/write
> > from the btrfs file system. There are no kernel opps or any other errors
> > messages in any of my logs. This happens if I have compression on or
> > not. I'd be happy to fix this issue but I don't have a clue about where
> > to start looking for what is wrong.
> >
> > Could someone please help me?
>
> Thanks for working on this. The first step is to figure out what ls is
> doing, and my guess is trying to read block groups. Do a sysrq-w while
> it is hung and send the results along.
>
> -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] 5+ messages in thread
* Re: btrfs lockup after mounting for a second time on 2.6.26
2009-02-12 14:51 ` Chris Mason
2009-02-12 16:57 ` Lee Trager
@ 2009-02-12 17:08 ` Lee Trager
2009-02-18 20:51 ` Lee Trager
2 siblings, 0 replies; 5+ messages in thread
From: Lee Trager @ 2009-02-12 17:08 UTC (permalink / raw)
To: Chris Mason; +Cc: Lee Trager, Btrfs Development List
Opps didn't include the entire thing last time...
[ 227.637684] SysRq : Show Blocked State
[ 227.639369] task PC stack pid father
[ 227.639369] ls D f784b9d4 0 3101 3003
[ 227.639369] f74e4da0 00000082 0000d950 f784b9d4 0000d950 f74e4f2c c1815fa0 00000001
[ 227.639369] f784b9cc ffff9728 c18031b4 c013604c 00000000 00000000 00000000 000000ff
[ 227.639369] c1815fa0 0145b000 c18031b4 c015688a c02b8498 f3459bb4 f3459bb4 c01568bd
[ 227.639369] Call Trace:
[ 227.639369] [<c013604c>] getnstimeofday+0x37/0xbc
[ 227.639369] [<c015688a>] sync_page+0x0/0x36
[ 227.639369] [<c02b8498>] io_schedule+0x49/0x80
[ 227.639369] [<c01568bd>] sync_page+0x33/0x36
[ 227.639369] [<c02b85c4>] __wait_on_bit_lock+0x2a/0x52
[ 227.639369] [<c015687c>] __lock_page+0x4e/0x54
[ 227.639369] [<c0131909>] wake_bit_function+0x0/0x3c
[ 227.639369] [<f8ce8312>] read_extent_buffer_pages+0x133/0x2f1 [btrfs]
[ 227.639369] [<c0117b50>] kmap_atomic_prot+0x9d/0xcc
[ 227.639369] [<f8ccd550>] btree_read_extent_buffer_pages+0x39/0x8c [btrfs]
[ 227.639369] [<f8ccf219>] btree_get_extent+0x0/0x173 [btrfs]
[ 227.639369] [<f8ccd856>] read_tree_block+0x29/0x4c [btrfs]
[ 227.639369] [<f8cb9c4a>] read_node_slot+0xa4/0xb2 [btrfs]
[ 227.639369] [<f8cbe46f>] btrfs_next_leaf+0x16f/0x27d [btrfs]
[ 227.639369] [<f8cc080a>] cache_block_group+0xe9/0x2a0 [btrfs]
[ 227.639369] [<c0184354>] alloc_inode+0x12e/0x186
[ 227.639369] [<f8cc1554>] find_free_extent+0x32a/0x7b2 [btrfs]
[ 227.639369] [<f8cc1bb1>] __btrfs_reserve_extent+0x1d5/0x370 [btrfs]
[ 227.639369] [<f8cc1d8b>] btrfs_reserve_extent+0x3f/0x61 [btrfs]
[ 227.639369] [<f8cbddbb>] btrfs_search_slot+0x257/0x79c [btrfs]
[ 227.639369] [<c0117c79>] kunmap_atomic+0x67/0x8a
[ 227.639369] [<f8ccccff>] btrfs_lookup_inode+0x27/0x88 [btrfs]
[ 227.639369] [<f8cd56c0>] btrfs_update_inode+0x3d/0xae [btrfs]
[ 227.639369] [<f8cd64e4>] btrfs_dirty_inode+0x3d/0x4a [btrfs]
[ 227.639369] [<c018cc33>] __mark_inode_dirty+0x21/0x12a
[ 227.639369] [<c0184f0a>] touch_atime+0xc7/0xd1
[ 227.639369] [<c017e8df>] vfs_readdir+0x75/0x8c
[ 227.639369] [<c017e6ec>] filldir64+0x0/0xc5
[ 227.639369] [<c017e959>] sys_getdents64+0x63/0xa5
[ 227.639369] [<c0103853>] sysenter_past_esp+0x78/0xb1
[ 227.639369] =======================
[ 227.639369] Sched Debug Version: v0.07, 2.6.26-1-686 #1
[ 227.639369] now at 210726.291061 msecs
[ 227.639369] .sysctl_sched_latency : 40.000000
[ 227.639369] .sysctl_sched_min_granularity : 8.000000
[ 227.639369] .sysctl_sched_wakeup_granularity : 20.000000
[ 227.639369] .sysctl_sched_child_runs_first : 0.000001
[ 227.639369] .sysctl_sched_features : 895
[ 227.639369]
[ 227.639369] cpu#0, 2200.225 MHz
[ 227.639369] .nr_running : 2
[ 227.639369] .load : 2048
[ 227.639369] .nr_switches : 34074
[ 227.639369] .nr_load_updates : 15468
[ 227.639369] .nr_uninterruptible : 4294967191
[ 227.639369] .jiffies : 4294944976
[ 227.639369] .next_balance : 4294.945040
[ 227.639369] .curr->pid : 3060
[ 227.639369] .clock : 210721.964922
[ 227.639369] .cpu_load[0] : 2048
[ 227.639369] .cpu_load[1] : 1024
[ 227.639369] .cpu_load[2] : 519
[ 227.639369] .cpu_load[3] : 299
[ 227.639369] .cpu_load[4] : 214
[ 227.639369]
[ 227.639369] cfs_rq[0]:
[ 227.639369] .exec_clock : 0.000000
[ 227.639369] .MIN_vruntime : 49281.152431
[ 227.639369] .min_vruntime : 49309.797267
[ 227.639369] .max_vruntime : 49281.152431
[ 227.639369] .spread : 0.000000
[ 227.639369] .spread0 : 0.000000
[ 227.639369] .nr_running : 2
[ 227.639369] .load : 2048
[ 227.639369] .nr_spread_over : 0
[ 227.639369]
[ 227.639369] runnable tasks:
[ 227.639369] task PID tree-key switches prio exec-runtime sum-exec sum-sleep
[ 227.639369] ----------------------------------------------------------------------------------------------------------
[ 227.639369] vmware-guestd 2151 49281.152431 2020 120 0 0 0.000000 0.000000 0.000000 /
[ 227.639369] R bash 3060 49295.747111 63 120 0 0 0.000000 0.000000 0.000000 /
[ 227.639369]
[ 227.639369] cpu#1, 2200.225 MHz
[ 227.639369] .nr_running : 2
[ 227.639369] .load : 2048
[ 227.639369] .nr_switches : 26399
[ 227.639369] .nr_load_updates : 14353
[ 227.639369] .nr_uninterruptible : 106
[ 227.639369] .jiffies : 4294944976
[ 227.639369] .next_balance : 4294.945104
[ 227.639369] .curr->pid : 2411
[ 227.639369] .clock : 210728.301926
[ 227.639369] .cpu_load[0] : 2048
[ 227.639369] .cpu_load[1] : 1024
[ 227.639369] .cpu_load[2] : 519
[ 227.639369] .cpu_load[3] : 321
[ 227.639369] .cpu_load[4] : 275
[ 227.639369]
[ 227.639369] cfs_rq[1]:
[ 227.639369] .exec_clock : 0.000000
[ 227.639369] .MIN_vruntime : 34787.608965
[ 227.639369] .min_vruntime : 34826.431444
[ 227.639369] .max_vruntime : 34787.608965
[ 227.639369] .spread : 0.000000
[ 227.639369] .spread0 : -14483.365823
[ 227.639369] .nr_running : 2
[ 227.639369] .load : 2048
[ 227.639369] .nr_spread_over : 0
[ 227.639369]
[ 227.639369] runnable tasks:
[ 227.639369] task PID tree-key switches prio exec-runtime sum-exec sum-sleep
[ 227.639369] ----------------------------------------------------------------------------------------------------------
[ 227.639369] R syslogd 2411 34791.757624 811 120 0 0 0.000000 0.000000 0.000000 /
[ 227.639369] klogd 2420 34787.608965 605 120 0 0 0.000000 0.000000 0.000000 /
[ 227.639369]
On Thu, Feb 12, 2009 at 09:51:12AM -0500, Chris Mason wrote:
> On Thu, 2009-02-12 at 01:31 -0500, Lee Trager wrote:
> > While running a few tests with the btrfs sources pulled from
> > btrfs-unstable patched with my patch to compile under 2.6.26 I
> > encountered a very weird problem. Everything works fine the first time I
> > mount the file system (either actual disk or loop back). When I
> > unmounted the file system and mounted it again(I'm not doing mount -o
> > remount ...) btrfs is completely unusable. When I tried to view some of
> > the data which I previously put on the btrfs partition by doing a simple
> > ls /mnt/btrfs in bash nothing happens. ls shows nothing, just hangs, and
> > I am unable to kill ls. The same thing happens when I try to copy a file
> > from my ext3 partition onto the btrfs partition after mounting it for a
> > second time. The rest of the system is completely usable and the only
> > things that are effects are applications which are trying to read/write
> > from the btrfs file system. There are no kernel opps or any other errors
> > messages in any of my logs. This happens if I have compression on or
> > not. I'd be happy to fix this issue but I don't have a clue about where
> > to start looking for what is wrong.
> >
> > Could someone please help me?
>
> Thanks for working on this. The first step is to figure out what ls is
> doing, and my guess is trying to read block groups. Do a sysrq-w while
> it is hung and send the results along.
>
> -chris
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: btrfs lockup after mounting for a second time on 2.6.26
2009-02-12 14:51 ` Chris Mason
2009-02-12 16:57 ` Lee Trager
2009-02-12 17:08 ` Lee Trager
@ 2009-02-18 20:51 ` Lee Trager
2 siblings, 0 replies; 5+ messages in thread
From: Lee Trager @ 2009-02-18 20:51 UTC (permalink / raw)
To: Chris Mason; +Cc: Lee Trager, Btrfs Development List
I took your suggestions from the phone conference today and tired them
out on my system.
It seems that even though 2.6.26 can not mount a btrfs partition a
second time 2.6.27 has no problem doing this. I created the the btrfs
parition on 2.6.26, copied data to it on 2.6.26, I tried to mount the
btrfs for a second time on 2.6.26 and I experienced the bug. I then
tried mounting the btrfs parition on 2.6.27 and it worked fine.
When I run vmstat it seems no data is comming from the btrfs partition
on 2.6.26. While I get some burts of data every few seconds it doesn't
seem I am getting anything from btrfs.
Lee
P.S Thanks for helping me get this working and answering my questions!
On Thu, Feb 12, 2009 at 09:51:12AM -0500, Chris Mason wrote:
> On Thu, 2009-02-12 at 01:31 -0500, Lee Trager wrote:
> > While running a few tests with the btrfs sources pulled from
> > btrfs-unstable patched with my patch to compile under 2.6.26 I
> > encountered a very weird problem. Everything works fine the first time I
> > mount the file system (either actual disk or loop back). When I
> > unmounted the file system and mounted it again(I'm not doing mount -o
> > remount ...) btrfs is completely unusable. When I tried to view some of
> > the data which I previously put on the btrfs partition by doing a simple
> > ls /mnt/btrfs in bash nothing happens. ls shows nothing, just hangs, and
> > I am unable to kill ls. The same thing happens when I try to copy a file
> > from my ext3 partition onto the btrfs partition after mounting it for a
> > second time. The rest of the system is completely usable and the only
> > things that are effects are applications which are trying to read/write
> > from the btrfs file system. There are no kernel opps or any other errors
> > messages in any of my logs. This happens if I have compression on or
> > not. I'd be happy to fix this issue but I don't have a clue about where
> > to start looking for what is wrong.
> >
> > Could someone please help me?
>
> Thanks for working on this. The first step is to figure out what ls is
> doing, and my guess is trying to read block groups. Do a sysrq-w while
> it is hung and send the results along.
>
> -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] 5+ messages in thread