From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-f170.google.com ([209.85.220.170]:57279 "EHLO mail-vc0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751901Ab3LPAQJ (ORCPT ); Sun, 15 Dec 2013 19:16:09 -0500 Received: by mail-vc0-f170.google.com with SMTP id la4so2771913vcb.1 for ; Sun, 15 Dec 2013 16:16:09 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20131215233959.GA7260@pyropus.ca> References: <46A0D70E-99DF-46FE-A4E8-71E9AC45129F@colorremedies.com> <337E6C9D-298E-4F77-91D7-648A7C65D360@colorremedies.com> <20131215233959.GA7260@pyropus.ca> Date: Mon, 16 Dec 2013 01:16:08 +0100 Message-ID: Subject: Re: Blocket for more than 120 seconds From: Hans-Kristian Bakke To: Btrfs BTRFS Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: There are actually more. Like this one: http://iohq.net/index.php?title=Btrfs:RAID_5_Rsync_Freeze It seems to be the exact same issue as I have, as I too can't do high speed rsyncs writing to the btrfs array without blocking (reading is fine). Mvh Hans-Kristian Bakke On 16 December 2013 00:39, Charles Cazabon wrote: > Chris Murphy wrote: >> On Dec 14, 2013, at 4:19 PM, Hans-Kristian Bakke wrote: >> >> > # btrfs fi df /storage/storage-vol0/ >> > Data, RAID10: total=13.89TB, used=12.99TB >> > System, RAID10: total=64.00MB, used=1.19MB >> > System: total=4.00MB, used=0.00 >> > Metadata, RAID10: total=21.00GB, used=17.59GB >> > >> By my count this is ~ 95.6% full. My past experience with other file >> systems, including btree file systems, is they get unpredictably fussy when >> they're this full. I start migration planning once 80% full is reached, and >> make it a policy to avoid going over 90% full. > > For what it's worth, I see exactly the same behaviour on a system where the > filesystem is only ~60% full, with more than 5TB of free space. All I have to > do is copy a single file of several gigabytes to the filesystem (over the > network, so it's only coming in at ~30MB/s) and I get similar task-blocked > messages: > > INFO: task btrfs-transacti:4118 blocked for more than 120 seconds. > Not tainted 3.12.5-custom+ #10 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > btrfs-transacti D ffff88082fd14140 0 4118 2 0x00000000 > ffff880805a06040 0000000000000002 ffff8807f7665d40 ffff8808078f2040 > 0000000000014140 ffff8807f7665fd8 ffff8807f7665fd8 ffff880805a06040 > 0000000000000001 ffff88082fd14140 ffff880805a06040 ffff8807f7665c70 > Call Trace: > [] ? __lock_page+0x66/0x66 > [] ? io_schedule+0x56/0x6c > [] ? sleep_on_page+0x7/0xc > [] ? __wait_on_bit+0x40/0x79 > [] ? find_get_pages_tag+0x66/0x121 > [] ? wait_on_page_bit+0x72/0x77 > [] ? wake_atomic_t_function+0x21/0x21 > [] ? filemap_fdatawait_range+0x66/0xfe > [] ? clear_extent_bit+0x25d/0x29d [btrfs] > [] ? btrfs_wait_marked_extents+0x79/0xca [btrfs] > [] ? btrfs_write_and_wait_transaction+0x6e/0x7e [btrfs] > [] ? btrfs_commit_transaction+0x651/0x843 [btrfs] > [] ? transaction_kthread+0xf4/0x191 [btrfs] > [] ? try_to_freeze_unsafe+0x30/0x30 [btrfs] > [] ? try_to_freeze_unsafe+0x30/0x30 [btrfs] > [] ? kthread+0x81/0x89 > [] ? paravirt_sched_clock+0x5/0x8 > [] ? __kthread_parkme+0x5d/0x5d > [] ? ret_from_fork+0x7c/0xb0 > [] ? __kthread_parkme+0x5d/0x5d > > > So it's not, at least in my case, due to the filesystem approaching full. > > I've seen this behaviour over many kernel versions; the above is with 3.12.5. > > Charles > -- > ----------------------------------------------------------------------- > Charles Cazabon > GPL'ed software available at: http://pyropus.ca/software/ > ----------------------------------------------------------------------- > -- > 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