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
next prev parent 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