From patchwork Mon Aug 22 19:25:58 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 1086192 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.4) with ESMTP id p7MJQ4Lt021851 for ; Mon, 22 Aug 2011 19:26:04 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753404Ab1HVT0B (ORCPT ); Mon, 22 Aug 2011 15:26:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50007 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753189Ab1HVT0A (ORCPT ); Mon, 22 Aug 2011 15:26:00 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7MJQ0Q8019265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 22 Aug 2011 15:26:00 -0400 Received: from localhost.localdomain.com (vpn-10-183.rdu.redhat.com [10.11.10.183]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7MJPxHY017725 for ; Mon, 22 Aug 2011 15:26:00 -0400 From: Josef Bacik To: linux-btrfs@vger.kernel.org Subject: [PATCH] Btrfs: don't increase the block_rsv's size when emergency allocating space Date: Mon, 22 Aug 2011 15:25:58 -0400 Message-Id: <1314041158-20533-1-git-send-email-josef@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 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 (demeter1.kernel.org [140.211.167.41]); Mon, 22 Aug 2011 19:26:19 +0000 (UTC) If we have to emergency reserve space we need to not increase the block_rsv size, otherwise we'll leak space. Take for instance delalloc, say we reserve 4k, and we use that 4k, and then we have to emergency allocate another 4k, we bump the size up to 8k, however we've only accounted for 4k in reservations in all of our supporting logic, so we'll go to free the 4k and end up having a size of 4k, which will cause us to later not free as much space. I saw this doing testing where I wasn't reserving enough space for something but was still leaking space, very frustrating. Thanks, Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 99ab571..1f1d3e8 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -5707,9 +5707,6 @@ use_block_rsv(struct btrfs_trans_handle *trans, ret = reserve_metadata_bytes(trans, root, block_rsv, blocksize, 0); if (!ret) { - spin_lock(&block_rsv->lock); - block_rsv->size += blocksize; - spin_unlock(&block_rsv->lock); return block_rsv; } else if (ret && block_rsv != global_rsv) { ret = block_rsv_use_bytes(global_rsv, blocksize);