public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Allison Henderson <allison.henderson@oracle.com>
To: "fstests@vger.kernel.org" <fstests@vger.kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"ZiyangZhang@linux.alibaba.com" <ZiyangZhang@linux.alibaba.com>
Cc: "djwong@kernel.org" <djwong@kernel.org>,
	"hsiangkao@linux.alibaba.com" <hsiangkao@linux.alibaba.com>
Subject: Re: [RESEND PATCH V2] common/populate: Ensure that S_IFDIR.FMT_BTREE is in btree format
Date: Sat, 3 Dec 2022 00:26:57 +0000	[thread overview]
Message-ID: <030e253f14fcdff29d43bafa690435be06abacb4.camel@oracle.com> (raw)
In-Reply-To: <20221202112740.1233028-1-ZiyangZhang@linux.alibaba.com>

On Fri, 2022-12-02 at 19:27 +0800, Ziyang Zhang wrote:
> Sometimes "$((128 * dblksz / 40))" dirents cannot make sure that
> S_IFDIR.FMT_BTREE could become btree format for its DATA fork.
> 
> Actually we just observed it can fail after apply our inode
> extent-to-btree workaround. The root cause is that the kernel may be
> too good at allocating consecutive blocks so that the data fork is
> still in extents format.
> 
> Therefore instead of using a fixed number, let's make sure the number
> of extents is large enough than (inode size - inode core size) /
> sizeof(xfs_bmbt_rec_t).
> 
> Suggested-by: "Darrick J. Wong" <djwong@kernel.org>
> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> Signed-off-by: Ziyang Zhang <ZiyangZhang@linux.alibaba.com>

New version looks much cleaner.  
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>

> ---
> V2: take Darrick's advice to cleanup code
>  common/populate | 28 +++++++++++++++++++++++++++-
>  common/xfs      | 17 +++++++++++++++++
>  2 files changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/common/populate b/common/populate
> index 6e004997..1ca76459 100644
> --- a/common/populate
> +++ b/common/populate
> @@ -71,6 +71,31 @@ __populate_create_dir() {
>         done
>  }
>  
> +# Create a large directory and ensure that it's a btree format
> +__populate_xfs_create_btree_dir() {
> +       local name="$1"
> +       local isize="$2"
> +       local icore_size="$(_xfs_inode_core_bytes)"
> +       # We need enough extents to guarantee that the data fork is
> in
> +       # btree format.  Cycling the mount to use xfs_db is too slow,
> so
> +       # watch for when the extent count exceeds the space after the
> +       # inode core.
> +       local max_nextents="$(((isize - icore_size) / 16))"
> +
> +       mkdir -p "${name}"
> +       d=0
> +       while true; do
> +               creat=mkdir
> +               test "$((d % 20))" -eq 0 && creat=touch
> +               $creat "${name}/$(printf "%.08d" "$d")"
> +               if [ "$((d % 40))" -eq 0 ]; then
> +                       nextents="$(_xfs_get_fsxattr nextents $name)"
> +                       [ $nextents -gt $max_nextents ] && break
> +               fi
> +               d=$((d+1))
> +       done
> +}
> +
>  # Add a bunch of attrs to a file
>  __populate_create_attr() {
>         name="$1"
> @@ -176,6 +201,7 @@ _scratch_xfs_populate() {
>  
>         blksz="$(stat -f -c '%s' "${SCRATCH_MNT}")"
>         dblksz="$(_xfs_get_dir_blocksize "$SCRATCH_MNT")"
> +       isize="$(_xfs_inode_size "$SCRATCH_MNT")"
>         crc="$(_xfs_has_feature "$SCRATCH_MNT" crc -v)"
>         if [ $crc -eq 1 ]; then
>                 leaf_hdr_size=64
> @@ -226,7 +252,7 @@ _scratch_xfs_populate() {
>  
>         # - BTREE
>         echo "+ btree dir"
> -       __populate_create_dir "${SCRATCH_MNT}/S_IFDIR.FMT_BTREE"
> "$((128 * dblksz / 40))" true
> +       __populate_xfs_create_btree_dir
> "${SCRATCH_MNT}/S_IFDIR.FMT_BTREE" "$isize"
>  
>         # Symlinks
>         # - FMT_LOCAL
> diff --git a/common/xfs b/common/xfs
> index 8ac1964e..0359e422 100644
> --- a/common/xfs
> +++ b/common/xfs
> @@ -1486,3 +1486,20 @@ _require_xfsrestore_xflag()
>         $XFSRESTORE_PROG -h 2>&1 | grep -q -e '-x' || \
>                         _notrun 'xfsrestore does not support -x
> flag.'
>  }
> +
> +
> +# Number of bytes reserved for a full inode record, which includes
> the
> +# immediate fork areas.
> +_xfs_inode_size()
> +{
> +       local mntpoint="$1"
> +
> +       $XFS_INFO_PROG "$mntpoint" | grep 'meta-data=.*isize' | sed -
> e 's/^.*isize=\([0-9]*\).*$/\1/g'
> +}
> +
> +# Number of bytes reserved for only the inode record, excluding the
> +# immediate fork areas.
> +_xfs_inode_core_bytes()
> +{
> +       echo 176
> +}


  reply	other threads:[~2022-12-03  0:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 11:27 [RESEND PATCH V2] common/populate: Ensure that S_IFDIR.FMT_BTREE is in btree format Ziyang Zhang
2022-12-03  0:26 ` Allison Henderson [this message]
2022-12-05 21:51   ` Darrick J. Wong
2022-12-06  3:13     ` Ziyang Zhang
2022-12-06  3:32       ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=030e253f14fcdff29d43bafa690435be06abacb4.camel@oracle.com \
    --to=allison.henderson@oracle.com \
    --cc=ZiyangZhang@linux.alibaba.com \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox