public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luís Henriques" <lhenriques@suse.de>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org, Jeff Layton <jlayton@kernel.org>,
	Xiubo Li <xiubli@redhat.com>,
	ceph-devel@vger.kernel.org
Subject: Re: [PATCH 2/2] src/attr_replace_test: dynamically adjust the max xattr size
Date: Wed, 8 Jun 2022 10:57:22 +0100	[thread overview]
Message-ID: <YqByggmCzXGAosM+@suse.de> (raw)
In-Reply-To: <20220608002315.GT1098723@dread.disaster.area>

On Wed, Jun 08, 2022 at 10:23:15AM +1000, Dave Chinner wrote:
> On Tue, Jun 07, 2022 at 04:15:13PM +0100, Luís Henriques wrote:
> > CephFS doesn't had a maximum xattr size.  Instead, it imposes a maximum
> > size for the full set of an inode's xattrs names+values, which by default
> > is 64K but it can be changed by a cluster admin.
> > 
> > Test generic/486 started to fail after fixing a ceph bug where this limit
> > wasn't being imposed.  Adjust dynamically the size of the xattr being set
> > if the error returned is -ENOSPC.
> 
> Ah, this shouldn't be getting anywhere near the 64kB limit unless
> ceph is telling userspace it's block size is > 64kB:
> 
> size = sbuf.st_blksize * 3 / 4;
> .....
> size = MIN(size, XATTR_SIZE_MAX);

Yep, that's exactly what is happening.  The cephfs kernel client reports
here the value that is being used for ceph "object size", which defaults
to 4M.  Hence, we'll set size to XATTR_SIZE_MAX.

> Regardless, the correct thing to do here is pass the max supported
> xattr size from the command line (because fstests knows what that it
> for each filesystem type) rather than hard coding
> XATTR_SIZE_MAX in the test.

OK, makes sense.  But then, for the ceph case, it becomes messy because we
also need to know the attribute name to compute the maximum size.  I guess
we'll need an extra argument for that too.

Cheers,
--
Luís

  reply	other threads:[~2022-06-08 10:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-07 15:15 [PATCH 0/2] Two xattrs-related fixes for ceph Luís Henriques
2022-06-07 15:15 ` [PATCH 1/2] generic/020: adjust max_attrval_size " Luís Henriques
2022-06-08  0:16   ` Dave Chinner
2022-06-08  9:46     ` Luís Henriques
2022-06-08 21:53       ` Dave Chinner
2022-06-09  9:09         ` Luís Henriques
2022-06-08  8:41   ` Xiubo Li
2022-06-07 15:15 ` [PATCH 2/2] src/attr_replace_test: dynamically adjust the max xattr size Luís Henriques
2022-06-07 15:33   ` Darrick J. Wong
2022-06-07 16:20     ` Luís Henriques
2022-06-07 16:51       ` [PATCH v2] " Luís Henriques
2022-06-08  1:17         ` Xiubo Li
2022-06-08  0:23   ` [PATCH 2/2] " Dave Chinner
2022-06-08  9:57     ` Luís Henriques [this message]
2022-06-08 21:59       ` Dave Chinner
2022-06-09 10:32         ` Luís Henriques
2022-06-08  8:50   ` Xiubo Li

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=YqByggmCzXGAosM+@suse.de \
    --to=lhenriques@suse.de \
    --cc=ceph-devel@vger.kernel.org \
    --cc=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    --cc=jlayton@kernel.org \
    --cc=xiubli@redhat.com \
    /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