Gregory Farnum <gfarnum@xxxxxxxxxx> writes:
On Thu, May 26, 2022 at 6:10 PM Xiubo Li <xiubli@xxxxxxxxxx> wrote:Right now the max_xattr_pairs_size seems to be something that can be set
Makes sense to me — this is really a property of the filesystem, not a
On 5/27/22 8:44 AM, Jeff Layton wrote:
On Fri, 2022-05-27 at 08:36 +0800, Xiubo Li wrote:AFAIK, each process in ceph it will have its own copy of the
On 5/27/22 2:39 AM, Jeff Layton wrote:Right, but the MDS's in general don't use local config files. Where are
A question:It sounds like what the "max_file_size" does, which will be recorded in
How do the MDS's discover this setting? Do they get it from the mons? If
so, I wonder if there is a way for the clients to query the mon for this
instead of having to extend the MDS protocol?
the 'mdsmap'.
While currently the "max_xattr_pairs_size" is one MDS's option for each
daemon and could set different values for each MDS.
these settings stored? Could the client (potentially) query for them?
"CephContext". I don't know how to query all of them but I know there
have some API such as "rados_conf_set/get" could do similar things.
Not sure whether will it work in our case.
I'm pretty sure the client does fetch and parse the mdsmap. If it'sYeah, IMO just making this option to be like the "max_file_size" is more
there then it could grab the setting for all of the MDS's at mount time
and settle on the lowest one.
I think a solution like that might be more resilient than having to
fiddle with feature bits and such...
appropriate.
daemon, so it should be propagated through common filesystem state.
on each MDS, so definitely not a filesystem property. To be honest, I
think it's nasty to have this knob in the first place because it will
allow an admin to set it to a value that will allow clients to blowup the
MDS cluster.
I guess Luis' https://github.com/ceph/ceph/pull/46357 should beJust to confirm, by "to do it that way" you mean to move that setting into
updated to do it that way?
the mdsmap, right?
I see some discussion there about handlingYeah, this is where the feature bit came from. This would allow old
old clients which don't recognize these limits as well.
clients to be identified so that the MDS would not give them 'Xx'
capabilities. Old clients would be able to set xattrs but not to buffer
them, i.e. they'd be forced to do the SETXATTR synchronously.
Cheers,