Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Ritesh Harjani <riteshh@linux.ibm.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	fstests@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 9/9] common/attr: Reduce MAX_ATTRS to leave some overhead for 64K blocksize
Date: Fri, 9 Jul 2021 10:42:29 +0530	[thread overview]
Message-ID: <20210709051229.psxw6fh4aaecuy6r@riteshh-domain> (raw)
In-Reply-To: <YNzD90/uocoRveYq@mit.edu>

On 21/06/30 03:20PM, Theodore Ts'o wrote:
> On Wed, Jun 30, 2021 at 08:51:50AM -0700, Darrick J. Wong wrote:
> > On Mon, Jun 14, 2021 at 11:58:13AM +0530, Ritesh Harjani wrote:
> > > Test generic/020 fails for ext4 with 64K blocksize. So increase some overhead
> > > value to reduce the MAX_ATTRS so that it can accomodate for 64K blocksize.
> > >
> > > Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
> > > ---
> > >  common/attr | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/common/attr b/common/attr
> > > index d3902346..e8661d80 100644
> > > --- a/common/attr
> > > +++ b/common/attr
> > > @@ -260,7 +260,7 @@ xfs|udf|pvfs2|9p|ceph|nfs)
> > >  	# Assume max ~1 block of attrs
> > >  	BLOCK_SIZE=`_get_block_size $TEST_DIR`
> > >  	# user.attribute_XXX="value.XXX" is about 32 bytes; leave some overhead
> > > -	let MAX_ATTRS=$BLOCK_SIZE/40
> > > +	let MAX_ATTRS=$BLOCK_SIZE/48
> >
> > 50% is quite a lot of overhead; maybe we should special-case this?
>
> The problem is that 32 bytes is an underestimate when i > 99 for
> user.attribute_$i=value_$i.  And with a 4k blocksize, MAX_ATTRS =
> 4096 / 40 = 102.
>
> The exact calculation for ext4 is:
>
> fixed_block_overhead = 32
> fixed_entry_overhead = 16
> max_attr = (block_size - fixed_block_overhead) /
> 	(fixed_entry_overhead + round_up(len(attr_name), 4) +
> 	 round_up(len(value), 4))
>
> For 4k blocksizes, most of the attributes have an attr_name of
> "attribute_NN" which is 8, and "value_NN" which is 12.
>
> But for larger block sizes, we start having extended attributes of the
> form "attribute_NNN" or "attribute_NNNN", and "value_NNN" and
> "value_NNNN", which causes the round(len(..), 4) to jump up by 4
> bytes.  So round_up(len(attr_name, 4)) becomes 12 instead of 8, and
> round_up(len(value, 4)) becomes 16 instead of 12.  So:
>
> 	max_attrs = (block_size - 32) / (16 + 12 + 16)
> or
> 	max_attrs = (block_size - 32) / 44
>
> instead of:
>
> 	max_attrs = (block_size - 32) / (16 + 8 + 12)
> or
> 	max_attrs = (block_size - 32) / 36

Thanks for the indepth details. Yes, in my testing as well it was coming to be
around ~44%. But to be safe I chose 50%.
I verified from the code as well. We do have 32 bytes of overhead per block for
the the header. And per entry overhead of 16 bytes. The rounding happens for
both name (EXT4_XATTR_LEN) and value (EXT4_XATTR_SIZE) of attr.

Perhaps, it will be helpful if we update above info in ext4 documentation as
well. In that the rounding off is only mentioned for value and not for name
length.

>
> So special casing things for block sizes > 4k may very well make
> sense.  Perhaps it's even worth it to put in an ext[234] specific,
> exalc calculation for MAX_ATTRS in common/attr.

yes, will make these changes for ext[234] specific in common/attr.

-ritesh

  reply	other threads:[~2021-07-09  5:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14  6:28 [PATCH 0/9] 64K blocksize related fixes Ritesh Harjani
2021-06-14  6:28 ` [PATCH 1/9] ext4/003: Fix this test on 64K platform for dax config Ritesh Harjani
2021-06-30 16:27   ` Theodore Ts'o
2021-07-08  6:24     ` Ritesh Harjani
2021-07-08 12:51       ` Theodore Ts'o
2021-06-14  6:28 ` [PATCH 2/9] ext4/027: Correct the right code of block and inode bitmap Ritesh Harjani
2021-06-14 16:40   ` Darrick J. Wong
2021-06-14  6:28 ` [PATCH 3/9] ext4/306: Add -b blocksize parameter too to avoid failure with DAX config Ritesh Harjani
2021-06-30 16:29   ` Theodore Ts'o
2021-06-14  6:28 ` [PATCH 4/9] ext4/022: exclude this test for dax config on 64KB pagesize platform Ritesh Harjani
2021-06-30 16:36   ` Theodore Ts'o
2021-06-14  6:28 ` [PATCH 5/9] generic/031: Fix the test case for 64k blocksize config Ritesh Harjani
2021-06-30 15:50   ` Darrick J. Wong
2021-06-30 17:18     ` Theodore Ts'o
2021-07-08  9:49       ` Ritesh Harjani
2021-06-14  6:28 ` [PATCH 6/9] gitignore: Add 031.out file to .gitignore Ritesh Harjani
2021-06-30 16:36   ` Theodore Ts'o
2021-06-14  6:28 ` [PATCH 7/9] generic/620: Remove -b blocksize option for ext4 Ritesh Harjani
2021-06-30 17:07   ` Theodore Ts'o
2021-07-08 10:01     ` Ritesh Harjani
2021-06-14  6:28 ` [PATCH 8/9] common/attr: Cleanup end of line whitespaces issues Ritesh Harjani
2021-06-30 15:50   ` Darrick J. Wong
2021-06-30 17:19   ` Theodore Ts'o
2021-06-14  6:28 ` [PATCH 9/9] common/attr: Reduce MAX_ATTRS to leave some overhead for 64K blocksize Ritesh Harjani
2021-06-30 15:51   ` Darrick J. Wong
2021-06-30 19:20     ` Theodore Ts'o
2021-07-09  5:12       ` Ritesh Harjani [this message]
2021-06-30 13:30 ` [PATCH 0/9] 64K blocksize related fixes Ritesh Harjani

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=20210709051229.psxw6fh4aaecuy6r@riteshh-domain \
    --to=riteshh@linux.ibm.com \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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