From patchwork Fri Aug 11 04:45:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 9894937 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 17F47602DA for ; Fri, 11 Aug 2017 04:46:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 023B328BC9 for ; Fri, 11 Aug 2017 04:46:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EA06828C37; Fri, 11 Aug 2017 04:46:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5A9AA28BC9 for ; Fri, 11 Aug 2017 04:46:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751299AbdHKEpx (ORCPT ); Fri, 11 Aug 2017 00:45:53 -0400 Received: from mail-pg0-f50.google.com ([74.125.83.50]:35407 "EHLO mail-pg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750815AbdHKEpw (ORCPT ); Fri, 11 Aug 2017 00:45:52 -0400 Received: by mail-pg0-f50.google.com with SMTP id v189so11190839pgd.2 for ; Thu, 10 Aug 2017 21:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=PnI1LuWxJoBoZFTvuo50UsCXwZrByMJlIE2eDMZyEr0=; b=Pv+kF9smU5tjHWKgZ9cdXZyZzthuj257D60KmGXm7qJOyTmluEvaxnISsBsIO1kwot 2lZ4mEvMvcMf6DlRC8JtkZfXd9cPgaJubFHN7bhOvgH4qkpnk08pg6tbbFu+pi9YklXj AQteIr43NpvXue4Fj5nl/pIFyfCKrDwgFmiwdxho8Yla6iJegiVCmBxeP79eHQzz+4ht YHNHOA+NgqzrJlf/pqJO5jDvkAIX8BrHibhxmw6s+1YLgX4DtErbTyZZutPqLS3tH57Z gzi+UtZHHBtwC2V05PDwcv2ZNGxLzdN/XE21L+33H+WVZrjrmD3Nt0omSvmQaLWXfEpt GBtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=PnI1LuWxJoBoZFTvuo50UsCXwZrByMJlIE2eDMZyEr0=; b=LAMSuMUmbtcuMdYUc9tItTcCxPEneNYNsLhdTJ5MQ9S7/a53KTChL6jUl2bs7Jcc26 ORXITxr0Mxfng+uo26bfaAL/gO5GaaL+LCbsgC4Qo+1Ge82bCJ/q4IIGFs02Am7eUui8 xXz/FSoAbxaSaI4qaXNcLhsV0406BVs9zojc/hOWsI/oLNXr6YI3FZGtGF4AcZnPuf1c k/44DicTC6QfQ7BZnvvcOH14d2NS/L0l5iGS6wSvYHpUxJ2+wB7yzJrEF44zJq4/bkrz iJ5nxv9oojsMQph5P1L8i4tbeSSzqCQyOL8zYYLTVtd17uCfXpLUVlJsxtuf22zEpHtB aVYA== X-Gm-Message-State: AHYfb5hV6nca1izqYqNIicGp3A7DmmNKobDOdOOslyE1SXuO3eu+rlVG EFhh570249poCllE1NZt7w== X-Received: by 10.98.158.194 with SMTP id f63mr14674784pfk.288.1502426751624; Thu, 10 Aug 2017 21:45:51 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:180::1:363b]) by smtp.gmail.com with ESMTPSA id h8sm13061150pfe.81.2017.08.10.21.45.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 21:45:51 -0700 (PDT) From: Omar Sandoval To: linux-xfs@vger.kernel.org Cc: kernel-team@fb.com Subject: [PATCH] xfs: fix inobt inode allocation search optimization Date: Thu, 10 Aug 2017 21:45:45 -0700 Message-Id: X-Mailer: git-send-email 2.14.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Omar Sandoval When we try to allocate a free inode by searching the inobt, we try to find the inode nearest the parent inode by searching chunks both left and right of the chunk containing the parent. As an optimization, we cache the leftmost and rightmost records that we previously searched; if we do another allocation with the same parent inode, we'll pick up the search where it last left off. There's a bug in the case where we found a free inode to the left of the parent's chunk: we need to update the cached left and right records, but because we already reassigned the right record to point to the left, we end up assigning the left record to both the cached left and right records. This isn't a correctness problem strictly, but it can result in the next allocation rechecking chunks unnecessarily or allocating inodes further away from the parent than it needs to. Fix it by swapping the record pointer after we update the cached left and right records. Fixes: bd169565993b ("xfs: speed up free inode search") Signed-off-by: Omar Sandoval Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_ialloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c index ffd5a15d1bb6..abf5beaae907 100644 --- a/fs/xfs/libxfs/xfs_ialloc.c +++ b/fs/xfs/libxfs/xfs_ialloc.c @@ -1246,13 +1246,13 @@ xfs_dialloc_ag_inobt( /* free inodes to the left? */ if (useleft && trec.ir_freecount) { - rec = trec; xfs_btree_del_cursor(cur, XFS_BTREE_NOERROR); cur = tcur; pag->pagl_leftrec = trec.ir_startino; pag->pagl_rightrec = rec.ir_startino; pag->pagl_pagino = pagino; + rec = trec; goto alloc_inode; }