Bug #2288
closedlibcephfs: setxattr returns EEXIST following removexattr
0%
Description
running cephtest a couple of time (out of wip-testlibcephfs):
012-04-13 14:02:39.396164 7f42bf90e760 1 -- 192.168.106.226:0/1008300 --> mds.0 192.168.106.223:6803/22493 -- client_request(client.4164:13 rmxattr #10000000004 user.testxattr) v1 -- ?+0 0x1e7d260 2012-04-13 14:02:39.396453 7f42bb0e3700 1 -- 192.168.106.226:0/1008300 <== mds.0 192.168.106.223:6803/22493 29 ==== client_caps(revoke ino 10000000004 32 seq 2 caps=pAsLsFscr dirty=- wanted=pFscr follows 0 size 0/0 ts 1 mtime 2012-04-13 13:46:52.957378) v2 ==== 180+0+0 (1463032935 0 0) 0x1e7a1f0 con 0x7f42b4003980 2012-04-13 14:02:39.396481 7f42bb0e3700 1 -- 192.168.106.226:0/1008300 --> mds.0 192.168.106.223:6803/22493 -- client_caps(update ino 10000000004 32 seq 2 caps=pAsLsFscr dirty=- wanted=pFscr follows 0 size 0/0 ts 1 mtime 2012-04-13 13:46:52.957378) v2 -- ?+0 0x7f42b400aa80 2012-04-13 14:02:39.396801 7f42bb0e3700 1 -- 192.168.106.226:0/1008300 <== mds.0 192.168.106.223:6803/22493 30 ==== client_reply(???:13 = 0 Success unsafe) v1 ==== 316+0+0 (3850604899 0 0) 0x1e7a1f0 con 0x7f42b4003980 2012-04-13 14:02:39.396877 7f42bf90e760 1 -- 192.168.106.226:0/1008300 --> mds.0 192.168.106.223:6803/22493 -- client_request(client.4164:14 setxattr #10000000004 user.testxattr) v1 -- ?+7 0x1e7d260 2012-04-13 14:02:39.396928 7f42bb0e3700 1 -- 192.168.106.226:0/1008300 <== mds.0 192.168.106.223:6803/22493 31 ==== client_reply(???:11 = 0 Success safe) v1 ==== 27+0+0 (55976111 0 0) 0x1e7e540 con 0x7f42b4003980 2012-04-13 14:02:39.397308 7f42bb0e3700 1 -- 192.168.106.226:0/1008300 <== mds.0 192.168.106.223:6803/22493 32 ==== client_caps(revoke ino 10000000004 32 seq 4 caps=pAsLsFscr dirty=- wanted=pFscr follows 0 size 0/0 ts 1 mtime 2012-04-13 13:46:52.957378) v2 ==== 180+0+0 (1307836803 0 0) 0x1e7a480 con 0x7f42b4003980 2012-04-13 14:02:39.397332 7f42bb0e3700 1 -- 192.168.106.226:0/1008300 --> mds.0 192.168.106.223:6803/22493 -- client_caps(update ino 10000000004 32 seq 4 caps=pAsLsFscr dirty=- wanted=pFscr follows 0 size 0/0 ts 1 mtime 2012-04-13 13:46:52.957378) v2 -- ?+0 0x7f42b400afc0 2012-04-13 14:02:39.397368 7f42bb0e3700 1 -- 192.168.106.226:0/1008300 <== mds.0 192.168.106.223:6803/22493 33 ==== client_reply(???:14 = -17 File exists safe) v1 ==== 27+0+0 (309390617 0 0) 0x1e7a830 con 0x7f42b4003980 ceph_setxattr error: (17) File exists
Running it again succeeds, but the following listxattrs will fail.
Updated by Greg Farnum about 12 years ago
- Status changed from New to 12
- Priority changed from Normal to Low
More info:
That branch has a patch which adds a call to removexattr before the setxattr. If you run testceph twice in a row (and no, testceph does not clean up after itself when done running, or before starting), the second time it fails out on the setxattr with an EEXIST.
I've checked and that is coming out of the MDS. Looks like it's because the MDS is sending back an early_reply on the remove_xattr, then the client is sending in the setxattr (which fails while looking at cur_inode->xattrs, because so far only the projected xattrs have changed)) and failing, then the MDS finishes the remove_xattr.
I can look into solving this more on request, but it's an MDS bug and I'm not immediately sure how to deal with it since I believe we're following our idioms in both functions. sigh
Updated by Sage Weil over 11 years ago
the problem is that it's not looking at the projected xattrs when it should. the logically simplest thing would be to move the xattr map into inode_t where it probably belongs. that expands the overhead associated with projecting changes, but makes the code simple.
alternatively, all of the setxattr and removexattr functions need to determine up front whether they are operating on projected or committed structs. probably the way to go.
Updated by Sage Weil over 11 years ago
- Project changed from Ceph to CephFS
- Category deleted (
1)
Updated by Greg Farnum over 11 years ago
SamL did some stuff involving projected xattrs; was this problem included in that set of changes or is it more complicated?
Updated by Sam Lang over 11 years ago
Ah, I wasn't aware of this bug. The commit you mentioned is 323a52ee909621ed0169b86e158370394ba36f62. It makes removexattr operate on the projected xattrs (due to a similar but different setxattr,removexattr pattern), but doesn't actually change handle_client_setxattr to do the same, so this is probably still a bug and needs a similar mod to handle_client_setxattr to check the projected xattrs. I'll add a proper test to test_libcephfs to make sure this is still an issue and patch it shortly.
Updated by Sage Weil over 11 years ago
- Assignee changed from Greg Farnum to Sam Lang
- Priority changed from Low to Normal
Updated by Greg Farnum about 10 years ago
- Assignee deleted (
Sam Lang) - Priority changed from Normal to High
Confirmed MDS bug!
Updated by Greg Farnum about 10 years ago
- Assignee set to Zheng Yan
commit:48e55d9 is in master and contains the simpler handle_client_setxattr() fix discussed above. Thanks Zheng!