All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Chandan Babu R <chandanrlinux@gmail.com>
Cc: linux-xfs@vger.kernel.org, david@fromorbit.com,
	bfoster@redhat.com, hch@infradead.org
Subject: Re: [PATCH 5/7] xfs: Use 2^27 as the maximum number of directory extents
Date: Mon, 8 Jun 2020 09:52:17 -0700	[thread overview]
Message-ID: <20200608165217.GE1334206@magnolia> (raw)
In-Reply-To: <20200606082745.15174-6-chandanrlinux@gmail.com>

On Sat, Jun 06, 2020 at 01:57:43PM +0530, Chandan Babu R wrote:
> The maximum number of extents that can be used by a directory can be
> calculated as shown below. (FS block size is assumed to be 512 bytes
> since the smallest allowed block size can create a BMBT of maximum
> possible height).
> 
> Maximum number of extents in data space =
> XFS_DIR2_SPACE_SIZE / 2^9 = 32GiB / 2^9 = 2^26.
> 
> Maximum number (theoretically) of extents in leaf space =
> 32GiB / 2^9 = 2^26.

Hm.  The leaf hash entries are 8 bytes long, whereas I think directory
entries occupy at least 16 bytes.  Is there a situation where the number
of dir leaf/dabtree blocks can actually hit the 32G section size limit?

> Maximum number of entries in a free space index block
> = (512 - (sizeof struct xfs_dir3_free_hdr)) / (sizeof struct
>                                                xfs_dir2_data_off_t)
> = (512 - 64) / 2 = 224
> 
> Maximum number of extents in free space index =
> (Maximum number of extents in data segment) / 224 =
> 2^26 / 224 = ~2^18
> 
> Maximum number of extents in a directory =
> Maximum number of extents in data space +
> Maximum number of extents in leaf space +
> Maximum number of extents in free space index =
> 2^26 + 2^26 + 2^18 = ~2^27

I calculated the exact expression here, and got:

2^26 + 2^26 + (2^26/224) = 134,517,321

This requires 28 bits of space, doesn't it?

Granted I bet the leaf section won't come within 300,000 nextents of the
2^26 you've assumed for it, so I suspect that in real world scenarios,
27 bits is enough.  But if you're anticipating a totally full leaf
section under extreme fragmentation, then MAXDIREXTNUM ought to be able
to handle that.

(Assuming I did any of that math correctly. ;))

--D

> 
> This commit defines the macro MAXDIREXTNUM to have the value 2^27 and
> this in turn is used in calculating the maximum height of a directory
> BMBT.
> 
> Signed-off-by: Chandan Babu R <chandanrlinux@gmail.com>
> ---
>  fs/xfs/libxfs/xfs_bmap.c  | 2 +-
>  fs/xfs/libxfs/xfs_types.h | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
> index 8b0029b3cecf..f75b70ae7b1f 100644
> --- a/fs/xfs/libxfs/xfs_bmap.c
> +++ b/fs/xfs/libxfs/xfs_bmap.c
> @@ -81,7 +81,7 @@ xfs_bmap_compute_maxlevels(
>  	if (whichfork == XFS_DATA_FORK) {
>  		sz = XFS_BMDR_SPACE_CALC(MINDBTPTRS);
>  		if (dir_bmbt)
> -			maxleafents = MAXEXTNUM;
> +			maxleafents = MAXDIREXTNUM;
>  		else
>  			maxleafents = MAXEXTNUM;
>  	} else {
> diff --git a/fs/xfs/libxfs/xfs_types.h b/fs/xfs/libxfs/xfs_types.h
> index 397d94775440..0a3041ad5bec 100644
> --- a/fs/xfs/libxfs/xfs_types.h
> +++ b/fs/xfs/libxfs/xfs_types.h
> @@ -60,6 +60,7 @@ typedef void *		xfs_failaddr_t;
>   */
>  #define	MAXEXTLEN	((xfs_extlen_t)0x001fffff)	/* 21 bits */
>  #define	MAXEXTNUM	((xfs_extnum_t)0x7fffffff)	/* signed int */
> +#define	MAXDIREXTNUM	((xfs_extnum_t)0x7ffffff)	/* 27 bits */
>  #define	MAXAEXTNUM	((xfs_aextnum_t)0x7fff)		/* signed short */
>  
>  /*
> -- 
> 2.20.1
> 

  reply	other threads:[~2020-06-08 16:52 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-06  8:27 [PATCH 0/7] xfs: Extend per-inode extent counters Chandan Babu R
2020-06-06  8:27 ` [PATCH 1/7] xfs: Fix log reservation calculation for xattr insert operation Chandan Babu R
2020-06-19 14:33   ` Christoph Hellwig
2020-06-20 12:53     ` Chandan Babu R
2020-06-06  8:27 ` [PATCH 2/7] xfs: Check for per-inode extent count overflow Chandan Babu R
2020-06-08 16:24   ` Darrick J. Wong
2020-06-08 16:32     ` Darrick J. Wong
2020-06-09 14:22       ` Chandan Babu R
2020-06-09 17:07         ` Darrick J. Wong
2020-06-10  6:24           ` Chandan Babu R
2020-06-09 14:22     ` Chandan Babu R
2020-06-09 17:10       ` Darrick J. Wong
2020-06-19 14:36         ` Christoph Hellwig
2020-06-19 21:31           ` Darrick J. Wong
2020-06-20 12:53           ` Chandan Babu R
2020-06-06  8:27 ` [PATCH 3/7] xfs: Compute maximum height of directory BMBT separately Chandan Babu R
2020-06-08 20:59   ` Darrick J. Wong
2020-06-09 14:23     ` Chandan Babu R
2020-06-09 18:40       ` Darrick J. Wong
2020-06-10  6:23         ` Chandan Babu R
2020-06-11  6:38           ` Chandan Babu R
2020-06-06  8:27 ` [PATCH 4/7] xfs: Add "Use Dir BMBT height" argument to XFS_BM_MAXLEVELS() Chandan Babu R
2020-06-08 17:50   ` Darrick J. Wong
2020-06-09 14:23     ` Chandan Babu R
2020-06-06  8:27 ` [PATCH 5/7] xfs: Use 2^27 as the maximum number of directory extents Chandan Babu R
2020-06-08 16:52   ` Darrick J. Wong [this message]
2020-06-09 14:23     ` Chandan Babu R
2020-06-06  8:27 ` [PATCH 6/7] xfs: Extend data extent counter to 47 bits Chandan Babu R
2020-06-08 17:14   ` Darrick J. Wong
2020-06-09 14:23     ` Chandan Babu R
2020-08-31 21:05       ` Darrick J. Wong
2020-06-19 14:38   ` Christoph Hellwig
2020-06-20 12:52     ` Chandan Babu R
2020-06-06  8:27 ` [PATCH 7/7] xfs: Extend attr extent counter to 32 bits Chandan Babu R
2020-06-08 17:21   ` Darrick J. Wong
2020-06-09 14:22     ` Chandan Babu R
2020-06-19 14:39   ` Christoph Hellwig
2020-06-20 12:53     ` Chandan Babu R
2020-06-08 17:31 ` [PATCH 0/7] xfs: Extend per-inode extent counters Darrick J. Wong
2020-06-09 14:22   ` Chandan Babu R

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=20200608165217.GE1334206@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=chandanrlinux@gmail.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.