From: Eryu Guan <guan@eryu.me>
To: Hao Xu <haoxu@linux.alibaba.com>
Cc: fstests@vger.kernel.org,
Frank van der Linden <fllinden@amazon.com>,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH] common/attr: remove the MAX_ATTRS and MAX_ATTRVAL_SIZE for nfs
Date: Sun, 8 Aug 2021 21:41:57 +0800 [thread overview]
Message-ID: <YQ/fJW/56wW9g0VT@desktop> (raw)
In-Reply-To: <20210804074148.203065-1-haoxu@linux.alibaba.com>
On Wed, Aug 04, 2021 at 03:41:48PM +0800, Hao Xu wrote:
> The block size of localfs for nfs may be different with nfs itself.
> So it's pointless to test nfs on xattrs size, just remove the special
> judge code.
>
> Fixes: commit da3cdb3b91ca ("common/attr: set MAX_ATTR values correctly for NFS")
> Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
> ---
> common/attr | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/common/attr b/common/attr
> index 42ceab92335a..542dff34bf55 100644
> --- a/common/attr
> +++ b/common/attr
> @@ -253,7 +253,7 @@ _getfattr()
>
> # set maximum total attr space based on fs type
> case "$FSTYP" in
> -xfs|udf|pvfs2|9p|ceph|nfs)
> +xfs|udf|pvfs2|9p|ceph)
> MAX_ATTRS=1000
This makes generic/020 _notrun on nfs, I don't think that's what we
want.
I think MAX_ATTRS is a best-effort guess based on filesystem block size,
it's not a accurate hard limit. And if there's no good way to tell the
fs blocksize on nfs server side, then we could make a conservative
assumption, e.g. the blocksize is 1k, and colculate MAX_ATTRS and
MAX_ATTRVAL_SIZE based on that assumption.
Thanks,
Eryu
> ;;
> *)
> @@ -273,7 +273,7 @@ xfs|udf|btrfs)
> pvfs2)
> MAX_ATTRVAL_SIZE=8192
> ;;
> -9p|ceph|nfs)
> +9p|ceph)
> MAX_ATTRVAL_SIZE=65536
> ;;
> bcachefs)
> --
> 2.24.4
prev parent reply other threads:[~2021-08-08 13:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-04 7:41 [PATCH] common/attr: remove the MAX_ATTRS and MAX_ATTRVAL_SIZE for nfs Hao Xu
2021-08-04 16:48 ` Frank van der Linden
2021-08-08 13:41 ` Eryu Guan [this message]
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=YQ/fJW/56wW9g0VT@desktop \
--to=guan@eryu.me \
--cc=fllinden@amazon.com \
--cc=fstests@vger.kernel.org \
--cc=haoxu@linux.alibaba.com \
--cc=linux-nfs@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.