Project

General

Profile

Actions
Copy link

Bug #2288

closed

libcephfs: setxattr returns EEXIST following removexattr

Added by Yehuda Sadeh about 12 years ago. Updated about 10 years ago.

Status:
Resolved
Priority:
High
Assignee:
Zheng Yan
Category:
-
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
Regression:
Severity:
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

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.

Actions
Copy link
 #1

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

Actions
Copy link
 #2

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.

Actions
Copy link
 #3

Updated by Sage Weil over 11 years ago

  • Project changed from Ceph to CephFS
  • Category deleted (1)
Actions
Copy link
 #4

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?

Actions
Copy link
 #5

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.

Actions
Copy link
 #6

Updated by Sage Weil over 11 years ago

  • Assignee changed from Greg Farnum to Sam Lang
  • Priority changed from Low to Normal
Actions
Copy link
 #7

Updated by Greg Farnum about 10 years ago

  • Assignee deleted (Sam Lang)
  • Priority changed from Normal to High

Confirmed MDS bug!

Actions
Copy link
 #8

Updated by Zheng Yan about 10 years ago

  • Status changed from 12 to Resolved
Actions
Copy link
 #9

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!

Actions
Copy link

Also available in: Atom PDF