From patchwork Fri Apr 26 22:59:20 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jorge Guerra X-Patchwork-Id: 10919833 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 70C6192A for ; Fri, 26 Apr 2019 23:00:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5EFD528DFC for ; Fri, 26 Apr 2019 23:00:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 52CD728E98; Fri, 26 Apr 2019 23:00:35 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI 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 DC90C28DFC for ; Fri, 26 Apr 2019 23:00:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727056AbfDZXAd (ORCPT ); Fri, 26 Apr 2019 19:00:33 -0400 Received: from mail-pg1-f180.google.com ([209.85.215.180]:33338 "EHLO mail-pg1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727008AbfDZXAd (ORCPT ); Fri, 26 Apr 2019 19:00:33 -0400 Received: by mail-pg1-f180.google.com with SMTP id k19so2289275pgh.0 for ; Fri, 26 Apr 2019 16:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=ci33vwLVPPOUmq1oleO7pkJYqGBAKKbexZFkMNldVDI=; b=trWomKFvRNeodCAi+BeTHLw7wpbmGhhNxoHt5NgE7jJGwTa+XDInirGy4U45Cy2J61 OEKexOoAR+twcldaaWB614+kYfys5EuIkiP3gbA4XY2ADES7EWonFd+OGxfsSkJ2vF8N dnOjQxg6Zi5BovV/zRlMiA1fIDgmbgm7B+UutA7eKeKTe7J9MceBkWEhVK/3LyozO096 NpF8Ik19UC5b3EJ0J7keicm2DTERBIO6mnGlWIBFpaahDW90YM1cybKxum7zlDqu4F1W GAN1biAD5whAefelVT+fTVrAS4u/wBGKFCZAhyTyMyaSsqTrBGe+CLzK/7yenq9x6NE8 mUjA== 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=ci33vwLVPPOUmq1oleO7pkJYqGBAKKbexZFkMNldVDI=; b=ovYp3S2f9Nxb/ETfhNPPcOg643SXP0LxcCYBSv0qfZZqTpX7Umrlz5uncsxrSbK1Jq 01OlZWgziDzU1uDhh/7r0Wi81DKoPPwhmIz6bTSFy0GhRaw6PHfVLQHE5ZlAWC0Jvrly iBB7+n2hyqQvi33djJqK2sYw8xkagSNTIyQYyZdFTLL6TxCKt37nRfaVayVlkRruDGOb 33hu2q+lGY36dvPC0xZtzl77xS/qwzAr3o0Bl5VNVp1eC7cUuFubTjUUsmUehEnSFjPJ cilsHrfRm7RZUY4KboFsPMY3lioYUDz7Gx8iOnrahgyJ1TnB3+7JgQzs4sCMI8YbzRPH LOow== X-Gm-Message-State: APjAAAUsvy0rJoczb8zzCtvF4ibWAtLn6gyv7lRjjpGsj9vo03dM4Hvk hv01I0NAL0j8OcFsU/k9ko21mZGk X-Google-Smtp-Source: APXvYqw7hHgj5mFJ1NUEGkCJfx9HiPv4Tc1/a77s7Ytl0kM+Ujed+qKiypIC+PeaEF07HnikhTIYWg== X-Received: by 2002:a63:de11:: with SMTP id f17mr36325590pgg.94.1556319631823; Fri, 26 Apr 2019 16:00:31 -0700 (PDT) Received: from jorgeguerra-mbp.thefacebook.com ([199.201.64.136]) by smtp.gmail.com with ESMTPSA id n26sm49213488pfi.165.2019.04.26.16.00.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Apr 2019 16:00:30 -0700 (PDT) From: Jorge Guerra X-Google-Original-From: Jorge Guerra To: linux-xfs@vger.kernel.org Cc: osandov@osandov.com, Jorge Guerra Subject: [PATCH] xfs_db: Scan entire file system when using 'frag' Date: Fri, 26 Apr 2019 15:59:20 -0700 Message-Id: <20190426225920.34359-1-jorgeguerra@gmail.com> X-Mailer: git-send-email 2.13.5 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: Jorge Guerra While running the 'frag' command of 'xfs_db' we noticed that the tool is not scanning all the files in the file system. We noticed this when we modified the tool to print the inodes of all the files scanned. For example: $ find /mnt/xfsdisk -type f | wc -l 1782674 $ xfs_db -r -c frag /dev/sdXX | grep MB | awk '{print $5}' | paste -s -d+ | bc 656818 Upon inspecting the code we noticed that the scanfunc_ino function stops processing a given inode block once it encounters a free leaf. However, in practice we see that inodes are necessarily always layed out contiguously on the leaf node. This resulted in the 'frag' command skipping some valid inodes. In this change we modify the scanfunc_ino function to skip freed inodes. With the change in place we ran the same experiment again and noticed a more accurate file count: $ find /mnt/d0 -type f | wc -l 1810442 $ xfs_db -r -c frag /dev/sdXX | grep MB | awk '{print $5}' | paste -s -d+ | bc 1810442 Signed-off-by: Jorge Guerra Reviewed-by: Eric Sandeen Reviewed-by: Darrick J. Wong --- db/frag.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/db/frag.c b/db/frag.c index 5f33cb73..91395234 100644 --- a/db/frag.c +++ b/db/frag.c @@ -507,7 +507,7 @@ scanfunc_ino( for (j = 0; j < inodes_per_buf; j++) { if (XFS_INOBT_IS_FREE_DISK(&rp[i], ioff + j)) - goto next_buf; + continue; dip = (xfs_dinode_t *)((char *)iocur_top->data + ((off + j) << mp->m_sb.sb_inodelog)); process_inode(agf, agino + ioff + j, dip);