From patchwork Tue Feb 24 21:29:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 5875601 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 13B399F169 for ; Tue, 24 Feb 2015 21:29:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 232E620251 for ; Tue, 24 Feb 2015 21:29:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 250D720120 for ; Tue, 24 Feb 2015 21:29:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752445AbbBXV3u (ORCPT ); Tue, 24 Feb 2015 16:29:50 -0500 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:15720 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750955AbbBXV3t (ORCPT ); Tue, 24 Feb 2015 16:29:49 -0500 Received: from pps.filterd (m0004003 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t1OLNpbH004312 for ; Tue, 24 Feb 2015 13:29:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : mime-version : content-type; s=facebook; bh=0e98RnnKhtsBtCN6HpqSOLOdGEffTM4xUv6A4u8yp40=; b=HkViaOBA8KgyMhUU9Bbfka5odW+Ze2r9cPIjXqEgzay9zM/vuvN1FwXVJk7fXBEsxJyB zuAy3GdNXH0IuaKw29u9cGACQcmKk8iDUnj5VTRPWfoQPjI8vKmTFVVAmzjJTVZTKcUr LkHVpm/WMalIKhn9cTqUZR66RiCZhVhTD0g= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 1ss15bg0sw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 24 Feb 2015 13:29:48 -0800 Received: from localhost (192.168.57.29) by mail.thefacebook.com (192.168.16.23) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 24 Feb 2015 13:29:46 -0800 From: Josef Bacik To: Subject: [PATCH] Btrfs: make async space flushing suck less when we're full Date: Tue, 24 Feb 2015 16:29:45 -0500 Message-ID: <1424813385-25945-1-git-send-email-jbacik@fb.com> X-Mailer: git-send-email 1.8.3.1 MIME-Version: 1.0 X-Originating-IP: [192.168.57.29] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-24_06:2015-02-24, 2015-02-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=4.93938223655732e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.996183534634169 suspectscore=1 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.996183534634169 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.996183534634169 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502240186 X-FB-Internal: deliver Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We noticed on our gluster boxes that rm's when very full we'd take forever. This was because the async flusher thread was committing the transaction over and over because we had no delalloc, no delayed items and no room to allocate new block groups. So fix a few things 1) Don't commit the transaction. If we need to do it we will do it ourselves. 2) Don't requeue ourselves. Once we stopped committing the transaction we would end up burning a CPU by just requeueing ourselves over and over again because we thought we need to flush more. 3) Don't bother doing async reclaim if we're just full. If we have 98% of our space actually used then doing things async really isn't going to be helpful, so skip it. This patch made the rm's on our extremely full gluster boxes not take all eternity. Thanks, Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index b2f7cf4..2364c5f 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4277,8 +4277,13 @@ out: static inline int need_do_async_reclaim(struct btrfs_space_info *space_info, struct btrfs_fs_info *fs_info, u64 used) { - return (used >= div_factor_fine(space_info->total_bytes, 98) && - !btrfs_fs_closing(fs_info) && + u64 thresh = div_factor_fine(space_info->total_bytes, 98); + + /* If we're just plain full then async reclaim just slows us down. */ + if (space_info->bytes_used >= thresh) + return 0; + + return (used >= thresh && !btrfs_fs_closing(fs_info) && !test_bit(BTRFS_FS_STATE_REMOUNTING, &fs_info->fs_state)); } @@ -4333,10 +4338,7 @@ static void btrfs_async_reclaim_metadata_space(struct work_struct *work) if (!btrfs_need_do_async_reclaim(space_info, fs_info, flush_state)) return; - } while (flush_state <= COMMIT_TRANS); - - if (btrfs_need_do_async_reclaim(space_info, fs_info, flush_state)) - queue_work(system_unbound_wq, work); + } while (flush_state < COMMIT_TRANS); } void btrfs_init_async_reclaim_work(struct work_struct *work)