Bug #45521
closedmds: layout parser does not handle [-.] in pool names
0%
Description
$ bin/ceph osd pool create cephfa-foo $ bin/ceph fs add_data_pool a cephfa-foo $ setfattr -n ceph.dir.layout -v 'stripe_unit=524288 stripe_count=8 object_size=4194304 pool=cephfa-foo' foo setfattr: foo: Invalid argument
MDS log shows:
7f2260f54700 20 mds.0.server parse_layout_vxattr name layout value 'pool=cephfa-foo'
2020-05-13T17:59:51.205+0530 7f2260f54700 10 mds.0.server parsed {pool=cephfa} left '-foo'
7f2260f54700 7 mds.0.server reply_client_request -22 ((22) Invalid argument) client_request(client.4156:6 setxattr #0x10000000000 ceph.dir.layout 2020-05-13T17:59:51.204109+0530 caller_uid=0, caller_gid=0{0,}) v4
Updated by Jeff Layton almost 4 years ago
The kernel client only copies off the layout when given Fw or or Fr caps.
We could change the MDS to gratuitously set the layout field for any inode in the traces, and then just have the client always copy them. The expectation would be that you can't actually do anything with the layout without Fr or Fw, and we can just ensure that it's updated otherwise. We might need to do something to both client and MDS for that.
Another possibility:
The client currently does a getattr on most ceph vxattrs. The cap mask is usually 0, unless it's ceph.rstats* in which case it sets CEPH_CAP_FILE_WREXTEND. Is there a cap mask we could request that would give us the layout?
Updated by Ramana Raja almost 4 years ago
- Status changed from New to In Progress
Updated by Zheng Yan almost 4 years ago
Jeff Layton wrote:
The kernel client only copies off the layout when given Fw or or Fr caps.
is this behavior related to this issue?
We could change the MDS to gratuitously set the layout field for any inode in the traces, and then just have the client always copy them. The expectation would be that you can't actually do anything with the layout without Fr or Fw, and we can just ensure that it's updated otherwise. We might need to do something to both client and MDS for that.
Another possibility:
The client currently does a getattr on most ceph vxattrs. The cap mask is usually 0, unless it's ceph.rstats* in which case it sets CEPH_CAP_FILE_WREXTEND. Is there a cap mask we could request that would give us the layout?
Updated by Jeff Layton almost 4 years ago
Zheng Yan wrote:
is this behavior related to this issue?
Not at all -- I put this in the wrong tracker. Please disregard!
Updated by Patrick Donnelly almost 4 years ago
- Status changed from In Progress to Pending Backport
Updated by Nathan Cutler almost 4 years ago
- Copied to Backport #45678: octopus: mds: layout parser does not handle [-.] in pool names added
Updated by Nathan Cutler almost 4 years ago
- Copied to Backport #45679: nautilus: mds: layout parser does not handle [-.] in pool names added
Updated by Nathan Cutler almost 4 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".