All of lore.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 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.