From patchwork Wed Feb 11 20:08:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 5814301 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id B7A37BF440 for ; Wed, 11 Feb 2015 20:09:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D65C82015E for ; Wed, 11 Feb 2015 20:09:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ED57C201FA for ; Wed, 11 Feb 2015 20:09:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753531AbbBKUJE (ORCPT ); Wed, 11 Feb 2015 15:09:04 -0500 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:22235 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753380AbbBKUJD (ORCPT ); Wed, 11 Feb 2015 15:09:03 -0500 Received: from pps.filterd (m0004347 [127.0.0.1]) by m0004347.ppops.net (8.14.5/8.14.5) with SMTP id t1BK78gb008247 for ; Wed, 11 Feb 2015 12:09:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wit.ai; h=from : to : subject : date : message-id : mime-version : content-type; s=mx2; bh=5E0sCtcPlPRzo1TfBCuPaaUIpcK4fIlqqxHsnIzwuhE=; b=C0tP1KBca4NyH/sHTg3yfYmCT9ksbwXpXPku4ITi7twNY7SELnJzb+/x1dA1065eTG+e tV3s+xwm8Pgz7DZnVtNw0iEi7s9XPTyHIDN4uVgf2n1nSzOya7bkSvSf1OEtjEBe3pP+ 5w4di/flIMYAft1lWvPj67owv6p+dfrCn3KoD4prBOk8bckxYdV+AD7TlAkKnqmd8kqF 0JbGfMqSZY+EAjin9JG6MyIEwWlzdrpZEMZUDseAaWJDSk9UlR5zLH2IjLZPSb5p5yu/ oBXiJ8QYDcLS3j4ObHklJinFPuaJkeLTNzR5VfQUNvtBI/2rjpyxBHTWWEiEZDuneA/k Pg== 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=5E0sCtcPlPRzo1TfBCuPaaUIpcK4fIlqqxHsnIzwuhE=; b=HSYYWZ2BAdx/Z+LxkWycrbk73In0G9yxMYGKyvlsnPGJAXRjwVEcHmI0rbsrHMVHKkzO 0Zq6sADIcKWny27hQ1hEtg4GZsnmYig6UA+SJk60Taq4B7CcrhdSUKcsOPnw0CKqFZdt tR3jNpHjk1sjShkMsOQufZiU7mb9Lui5rpY= Received: from mail.thefacebook.com ([199.201.64.23]) by m0004347.ppops.net with ESMTP id 1sgdt080ax-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 11 Feb 2015 12:09:02 -0800 Received: from localhost (192.168.57.29) by mail.thefacebook.com (192.168.16.24) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 11 Feb 2015 12:09:01 -0800 From: Josef Bacik To: Subject: [PATCH 1/3] Btrfs: only adjust outstanding_extents when we do a short write Date: Wed, 11 Feb 2015 15:08:57 -0500 Message-ID: <1423685339-8278-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-11_04:2015-02-11, 2015-02-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=502.112 compositescore=0.996334338755742 urlsuspect_oldscore=0.996334338755742 suspectscore=1 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=62764 rbsscore=0.996334338755742 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502110201 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 have this weird dance where we always inc outstanding_extents when we do a O_DIRECT write, even if we allocate the entire range. To get around this we also drop the metadata space if we successfully write. This is an unnecessary dance, we only need to jack up outstanding_extents if we don't satisfy the entire range request in get_blocks_direct, otherwise we are good using our original reservation. So drop the unconditional inc and the drop of the metadata space that we have for the unconditional inc. Thanks, Signed-off-by: Josef Bacik Reviewed-by: Liu Bo --- fs/btrfs/inode.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 8a036ed..e78a2fd 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -7137,6 +7137,7 @@ static int btrfs_get_blocks_direct(struct inode *inode, sector_t iblock, u64 start = iblock << inode->i_blkbits; u64 lockstart, lockend; u64 len = bh_result->b_size; + u64 orig_len = len; int unlock_bits = EXTENT_LOCKED; int ret = 0; @@ -7272,9 +7273,11 @@ unlock: if (start + len > i_size_read(inode)) i_size_write(inode, start + len); - spin_lock(&BTRFS_I(inode)->lock); - BTRFS_I(inode)->outstanding_extents++; - spin_unlock(&BTRFS_I(inode)->lock); + if (len < orig_len) { + spin_lock(&BTRFS_I(inode)->lock); + BTRFS_I(inode)->outstanding_extents++; + spin_unlock(&BTRFS_I(inode)->lock); + } ret = set_extent_bit(&BTRFS_I(inode)->io_tree, lockstart, lockstart + len - 1, EXTENT_DELALLOC, NULL, @@ -8056,8 +8059,6 @@ static ssize_t btrfs_direct_IO(int rw, struct kiocb *iocb, else if (ret >= 0 && (size_t)ret < count) btrfs_delalloc_release_space(inode, count - (size_t)ret); - else - btrfs_delalloc_release_metadata(inode, 0); } out: if (wakeup)