Bug #10533
closedlibrados: duplicate object in rados_list() result
0%
Description
This occurred on a mixed firefly+next cluster with thrashing going on in the background.
It was detected by an rbd test that checks the number of data objects are in an image.
Relevant log excerpt:
2015-01-13T03:56:13.691 INFO:tasks.workunit.client.0.burnupi28.stderr:+ objects=1 2015-01-13T03:56:13.691 INFO:tasks.workunit.client.0.burnupi28.stderr:1 2015-01-13T03:56:13.691 INFO:tasks.workunit.client.0.burnupi28.stderr:+ echo 1 1 2015-01-13T03:56:13.692 INFO:tasks.workunit.client.0.burnupi28.stderr:+ [ 0 -eq 1 -o 1 1 = 1 ]
The '1 1' indicates that there were two objects with the same name (see https://github.com/ceph/ceph/blob/master/qa/workunits/rbd/import_export.sh#L12)
It's unclear if this is meant to be possible, but it could be fixed on the client side easily in librados.
Updated by Yuri Weinstein over 9 years ago
For reference - it was also caught by this job
http://qa-proxy.ceph.com/teuthology/teuthology-2015-01-12_17:13:01-upgrade:firefly-x-next-distro-basic-multi/700134/
Updated by Greg Farnum over 9 years ago
It's been a long time since I worked on the listing code and I think it's been rewritten since then, but once upon a time seeing objects multiple times was a definite possibility if there were state changes while the listing was in progress. How do you think we prevent it, keep a hash for which we know we've seen all objects, and not return anything prior to that point to the client?
Updated by Josh Durgin over 9 years ago
- Status changed from New to Won't Fix
The client is stateful, so yes, but according to sage split can cause problems, as can readdir being unpredictable and getting different sections of a hash range the client asks for. Due to this, I don't think it's worth trying to do anything clever on the client side to reduce dups.