Bug #2285: libcephfs: failure with empty name components - CephFS - Ceph

Actions

Copy link

Bug #2285

closed

libcephfs: failure with empty name components

Added by Yehuda Sadeh about 12 years ago. Updated over 11 years ago.

Status:

Resolved

Priority:

Low

Assignee:

Sam Lang

Category:

Target version:

% Done:

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

the following in client/testceph.cc fails:

// test empty name components
  my_fd = ret = ceph_open(cmount, "readdir_test//opened_file_1", O_RDONLY, 0666);

ceph_open O_RDONLY error: (2) No such file or directory

Actions

Copy link

Updated by Greg Farnum about 12 years ago

Status changed from New to In Progress

Oddly, this looks like it's a race. I can't reproduce it with any client debugging on...

Actions

Copy link

Updated by Greg Farnum about 12 years ago

Status changed from In Progress to 12
Priority changed from Normal to Low

Yep, it's client-local; there's no request to the MDS for this either.

Guess that means we don't care right now?

Actions

Copy link

Updated by Sage Weil over 11 years ago

Assignee changed from Greg Farnum to Sam Lang

Actions

Copy link

Updated by Sam Lang over 11 years ago

I noticed that the above test doesn't have O_CREAT, not sure if the file already existed in previous tests. The following test seems to behave as expected for me though: https://gist.github.com/3761908

Actions

Copy link

Updated by Sage Weil over 11 years ago

I suspect that differs from his failure because the paths are already cached on the client. Try creating the file, unmounting, remounting, and then doing the open?

Actions

Copy link

Updated by Sam Lang over 11 years ago

I tested this by working around #3186, first creating the file and then in a separate test running ceph_open as the original test did (with just O_RDONLY). The only difference with the above test is the preceding slash. "/readdir_test//opened_file_1" succeeds, but "readdir_test//opened_file_1" fails with ENOENT. This looks like correct behavior.

Actions

Copy link

Updated by Sam Lang over 11 years ago

Status changed from 12 to Fix Under Review

This was probably caused by the memory error in filepath (encoded member not getting initialized), which may explain why it wasn't always reproducible. Proposed fix: 2b543918994ceb2271b4589ba5022b3da922ed67 needs review.

Actions

Copy link