pacific: rgw: resolve empty ordered bucket listing results w/ CLS filtering *and* bucket index list produces incorrect result when non-ascii entries#45087
Conversation
|
To do the backport cleanly I needed the commit from #44815, which is currently DNM, so I marked this DNM too. |
|
jenkins retest this please |
|
This was missing a fixed bi_list test. Re-qa it please. (I've rebased on latest pacific) |
A recent PR that helped address the issue of non-ascii plain entries didn't cover all the bases, allowing I/O errors to be produced in some circumstances during a bucket index list (i.e., `radosgw-admin bi list ...`). This fixes those issue and does some additional clean-up. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com> (cherry picked from commit e714f0d) (cherry picked from commit 3473bf3)
When using asynchronous (concurrent) IO for bucket index requests, there are two int ids that are used that need to be kept separate -- shard id and request id. In many cases they're the same -- shard 0 gets request 0, and so forth. But in preparation for re-requests, those ids can diverge, where request 13 maps to shard 2. The existing code maintained the OIDs that went with each request. This PR also maintains the shard id as well. Documentation has been beefed up to help future developers navigate this. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com> (cherry picked from commit 9606346)
When doing an asynchronous/concurrent bucket index operation against multiple bucket index shards, a special error code is set aside to indicate that an "advancing" retry of a/some shard(s) is necessary. In that case another asynchronous call is made on the indicated shard(s) from the client (i.e., CLSRGWConcurrentIO). It is up to the subclass of CLSRGWConcurrentIO to handle the retry such that it "advances" and simply doesn't get stuck, looping forever. The retry functionality only works when the "need_multiple_rounds" functionality is not in use. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com> (cherry picked from commit 5d28307)
A previous PR moved the much of the filtering that's part of bucket listing to the CLS layer. One unanticipated result was that it is now possible for a call to return 0 entries. In such a case we want to retry the call with the marker moved forward (i.e., advanced), repeatedly if necessary, in order to either retrieve some entries or to hit the end of the entries. This PR adds that functionality. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com> (cherry picked from commit 423c183)
When "bucket index list" traverses the different regions in the bucket index assembling the output, it miscalculates how many entries to ask for at one point. This fixes that. This fixes previous "rgw: bucket index list can produce I/O errors". Credit for finding this bug goes to Soumya Koduri <skoduri@redhat.com>. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com> (cherry picked from commit aa76051)
Make sure marker is cleared. Put end-of-list check inside the conditional with the rest of the test. Add some additional testing. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com> (cherry picked from commit 1bf0581)
c561b3e to
0d103e7
Compare
ivancich
left a comment
There was a problem hiding this comment.
This looks good. Thank you for undertaking the effort! As mentioned in another comment, adding one more commit would fix some additional bugs and would save us another PR. Thank you for considering!
Fix bugs surrounding calculation of number of entries returned and whether the end of a listing range has been reached. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
…stent This provides more thorough and consistent function tracing in CLS/RGW when logging is set to 10 or higher. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
Adding more level 20 logging for bucket index listing. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
Done, I also brought in a dependent logging change to make 5b8af18 apply cleanly. |
|
jenkins retest this please |
backport tracker: https://tracker.ceph.com/issues/52075
backport of #42125 and #42404 and #44562
parent trackers: https://tracker.ceph.com/issues/51462 and https://tracker.ceph.com/issues/51429