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. -- 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
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 -- 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
Nothing shows up in dmesg. [ 8114.870020] ls R running task 0 3438 3375 0x00000004 [ 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+0x49/0x70 [ 8114.870020] [<ffffffffa0e84607>] ? shrink_delalloc+0x127/0x170 [btrfs] [ 8114.870020] [<ffffffffa0e84727>] ? reserve_metadata_bytes+0xd7/0x1f0 [btrfs] [ 8114.870020] [<ffffffffa0e84913>] ? btrfs_block_rsv_add+0x43/0x60 [btrfs] [ 8114.870020] [<ffffffff81085e00>] ? autoremove_wake_function+0x0/0x40 [ 8114.870020] [<ffffffffa0e8498b>] ? btrfs_trans_reserve_metadata+0x5b/0xa0 [btrfs] [ 8114.870020] [<ffffffffa0e9a0be>] ? start_transaction+0xbe/0x210 [btrfs] [ 8114.870020] [<ffffffff8116fa80>] ? filldir+0x0/0xf0 [ 8114.870020] [<ffffffffa0e9a423>] ? btrfs_start_transaction+0x13/0x20 [btrfs] [ 8114.870020] [<ffffffffa0e9d3e8>] ? btrfs_dirty_inode+0x98/0x120 [btrfs] [ 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 0x00000000 [ 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, > > > 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 >-- 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
On 18 November 2010 06:03, Brian Sullivan <bexamous@gmail.com> wrote:> Nothing shows up in dmesg. > > [ 8114.870020] ls R running task 0 3438 3375 0x00000004 > [ 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+0x49/0x70 > [ 8114.870020] [<ffffffffa0e84607>] ? shrink_delalloc+0x127/0x170 [btrfs] > [ 8114.870020] [<ffffffffa0e84727>] ? reserve_metadata_bytes+0xd7/0x1f0 [btrfs] > [ 8114.870020] [<ffffffffa0e84913>] ? btrfs_block_rsv_add+0x43/0x60 [btrfs] > [ 8114.870020] [<ffffffff81085e00>] ? autoremove_wake_function+0x0/0x40 > [ 8114.870020] [<ffffffffa0e8498b>] ? > btrfs_trans_reserve_metadata+0x5b/0xa0 [btrfs] > [ 8114.870020] [<ffffffffa0e9a0be>] ? start_transaction+0xbe/0x210 [btrfs] > [ 8114.870020] [<ffffffff8116fa80>] ? filldir+0x0/0xf0 > [ 8114.870020] [<ffffffffa0e9a423>] ? btrfs_start_transaction+0x13/0x20 [btrfs] > [ 8114.870020] [<ffffffffa0e9d3e8>] ? btrfs_dirty_inode+0x98/0x120 [btrfs] > [ 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 0x00000000 > [ 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/0x10Interesting. 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
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 sitting at 0: [ 420.110021] touch S ffff8803646c9a58 0 3337 3252 0x00000000 [ 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 [btrfs] [ 420.110021] [<ffffffffa0dbe98b>] btrfs_trans_reserve_metadata+0x5b/0xa0 [btrfs] [ 420.110021] [<ffffffffa0dd40be>] start_transaction+0xbe/0x210 [btrfs] [ 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 0x00000004 [ 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+0xf9/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 R running task 0 3438 3375 0x00000004 >> [ 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+0x49/0x70 >> [ 8114.870020] [<ffffffffa0e84607>] ? shrink_delalloc+0x127/0x170 [btrfs] >> [ 8114.870020] [<ffffffffa0e84727>] ? reserve_metadata_bytes+0xd7/0x1f0 [btrfs] >> [ 8114.870020] [<ffffffffa0e84913>] ? btrfs_block_rsv_add+0x43/0x60 [btrfs] >> [ 8114.870020] [<ffffffff81085e00>] ? autoremove_wake_function+0x0/0x40 >> [ 8114.870020] [<ffffffffa0e8498b>] ? >> btrfs_trans_reserve_metadata+0x5b/0xa0 [btrfs] >> [ 8114.870020] [<ffffffffa0e9a0be>] ? start_transaction+0xbe/0x210 [btrfs] >> [ 8114.870020] [<ffffffff8116fa80>] ? filldir+0x0/0xf0 >> [ 8114.870020] [<ffffffffa0e9a423>] ? btrfs_start_transaction+0x13/0x20 [btrfs] >> [ 8114.870020] [<ffffffffa0e9d3e8>] ? btrfs_dirty_inode+0x98/0x120 [btrfs] >> [ 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 0x00000000 >> [ 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 > > 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
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 -- 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
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 -- 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
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? 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. -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
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> 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? 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 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
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> 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? Â 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 able > 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
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.com> 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? 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 able >> 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
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.com> 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? Â 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 able > >> to write to the filesystem. > > > > So with the patch are you still seeing the 100% system time? > > > > -chris > > > > Yes, no change with patch.Ok, the short term solution is going to be adding another drive to your FS 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