From patchwork Mon Aug 1 15:21:34 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 1026112 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p71FLpHH016749 for ; Mon, 1 Aug 2011 15:21:51 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752965Ab1HAPVl (ORCPT ); Mon, 1 Aug 2011 11:21:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30461 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752832Ab1HAPVg (ORCPT ); Mon, 1 Aug 2011 11:21:36 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p71FLZFF016354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Aug 2011 11:21:35 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p71FLZI1005227 for ; Mon, 1 Aug 2011 11:21:35 -0400 Received: from localhost.localdomain (vpn-9-3.rdu.redhat.com [10.11.9.3]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p71FLYaf022317 for ; Mon, 1 Aug 2011 11:21:34 -0400 Message-ID: <4E36C47E.70309@redhat.com> Date: Mon, 01 Aug 2011 11:21:34 -0400 From: Josef Bacik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: linux-btrfs Subject: PLEASE TEST: Everybody who is seeing weird and long hangs X-Enigmail-Version: 1.1.2 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Mon, 01 Aug 2011 15:21:52 +0000 (UTC) Hello, We've seen a lot of reports of people having these constant long pauses when doing things like sync or such. The stack traces usually all look the same, one is btrfs-transaction stuck in btrfs_wait_marked_extents and one is btrfs-submit-# stuck in get_request_wait. I had originally thought this was due to the new plugging stuff, but I think it just makes the problem happen more quickly as we've seen that 2.6.38 which we thought was ok will still have the problem happen if given enough time. I _think_ this is because of the way we write out metadata in the transaction commit phase. We're doing write_on_page for every dirty page in the btree during the commit. This sucks because basically we end up with one bio per page, which makes us blow out our nr_requests constantly, which is why btrfs-submit-# is always stuck in get_request_wait. What we need to do instead is use filemap_fdatawrite which will do a WB_SYNC_ALL but will do it via writepages, so hopefully we will get less bios and this problem will go away. Please try this very hastily put together patch if you are experiencing this problem and let me know if it fixes it for you. Thanks, Josef mark); @@ -624,7 +626,8 @@ int btrfs_write_marked_extents(struct btrfs_root *root, } if (err) werr = err; - return werr; + */ +// return werr; } /* --- 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 diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index eb55863..86217a4 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -577,15 +577,17 @@ int btrfs_end_transaction_dmeta(struct btrfs_trans_handle *trans, int btrfs_write_marked_extents(struct btrfs_root *root, struct extent_io_tree *dirty_pages, int mark) { - int ret; - int err = 0; - int werr = 0; - struct page *page; +// int ret; +// int err = 0; +// int werr = 0; +// struct page *page; struct inode *btree_inode = root->fs_info->btree_inode; - u64 start = 0; - u64 end; - unsigned long index; +// u64 start = 0; +// u64 end; +// unsigned long index; + return filemap_fdatawrite(btree_inode->i_mapping); + /* while (1) { ret = find_first_extent_bit(dirty_pages, start, &start, &end,