New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kraken: rgw: rgw_file: FHCache residence check should be exhaustive #13841
Conversation
Jenkins retest this please (logs gone) |
@mattbenjamin: Whelp! |
@will test build... |
@smithfarm the handle print requires having merged 1d6c72f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approve modulo it builds :)
7a224a9
to
97ebfde
Compare
@mattbenjamin Thanks! |
@smithfarm sorry, we're not missing 1d6c72f, but need to understand the conflict (want to ensure that correct handle lifecycle commits all land); looks like empty dtor ~RGWFileHandle is correct |
@mattbenjamin No, not 1d6c72f (which is a jewel backport), but I did cherry-pick ef330f3 into this PR which will hopefully resolve the build issue. |
oh, now I see the conflict. I'll re-do that commit as well. |
97ebfde
to
3ee8776
Compare
@smithfarm basically kraken should I think get backports of all commits that reached jewel after kraken branched; kraken seems to be missing at least the following: |
@mattbenjamin First, I redid the cherry-picks, so the conflict is gone. Second, I tried cherry-picking 70ef7d4 and 2e66c7a on top of this PR and neither cherry-picks cleanly. |
@smithfarm I did search those on a jewel branch, I'll re-run on master; however, I do know that LIBRGW_FILE_VER_EXTRA (src/include/rados/rgw_file.h) is incorrect on Kraken |
@smithfarm proposed conflict resolutions on: |
bca21e8
to
e349a39
Compare
@mattbenjamin OK, integrated those fixes, updated trackers etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Jenkins re-test this please |
RGW NFS fhcache/RGWFileHandle operators assume existence of the full chain of parents from any object to the its fs_root--this is a consequence of the weakly-connected namespace design goal, and not a defect. This change ensures the invariant by taking a parent ref when objects are interned (when a parent ref is guaranteed). Parent refs are returned when objects are destroyed--essentially by the invariant, such a ref must exist. The extra ref is omitted when parent->is_root(), as that node is not in the LRU cache. Fixes: http://tracker.ceph.com/issues/18650 Signed-off-by: Matt Benjamin <mbenjamin@redhat.com> (cherry picked from commit 0e5299f)
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com> (cherry picked from commit ef330f3)
These are helpful for checking RGWFileHandle refcnt invariants. Signed-off-by: Matt Benjamin <mbenjamin@redhat.com> (cherry picked from commit 462034e)
This change includes 3 related changes: 1. add required lock flags for FHCache updates--this is a crash bug under concurrent update/lookup 2. omit to inc/dec refcnt on root filehandles in 2 places--the root handle current is not on the lru list, so it's not valid to do so 3. based on observation of LRU behavior during creates/deletes, update (cohort) LRU unref to move objects to LRU when their refcount falls to SENTINEL_REFCNT--this cheaply primes the current reclaim() mechanism, so very significanty improves space use (e.g., after deletes) in the absence of scans (which is common due to nfs-ganesha caching) Signed-off-by: Matt Benjamin <mbenjamin@redhat.com> (cherry picked from commit beaeff0)
Previously we assumed that !deleted handles were resident--there is an observed case where a !deleted handle is !linked. Since we currently use safe_link mode, an is_linked() check is available, and exhaustive. Fixes: http://tracker.ceph.com/issues/19111 Signed-off-by: Matt Benjamin <mbenjamin@redhat.com> (cherry picked from commit c0aa515)
Allow callers of rgw_lookup() on objects attested in an rgw_readdir() callback the ability to bypass exact match in RGWLibFS::stat_leaf() case 2, but restore exact match enforcement for general lookups. This preserves required common_prefix namespace behavior, but prevents clients from eerily permitting things like "cd sara0" via partial name match on "sara01." Fixes: http://tracker.ceph.com/issues/19059 Signed-off-by: Matt Benjamin <mbenjamin@redhat.com> (cherry picked from commit 70ef7d4) Conflicts: src/include/rados/rgw_file.h: trivial resolution src/rgw/rgw_file.cc: trivial resolution
The new type hints optimize object type deduction, when the rgw_lookup is called from an rgw_readdir callback. Fixes: http://tracker.ceph.com/issues/19623 Signed-off-by: Matt Benjamin <mbenjamin@redhat.com> (cherry picked from commit 2e66c7a) Conflicts: src/rgw/rgw_file.h: trivial resolution
e349a39
to
c46113e
Compare
@mattbenjamin In the end I merged this PR into #13871. The two commits that had conflicts (which you resolved) no longer conflicted when I cherry-picked them on top of the commits already in that PR. |
ok, cool
…On Tue, Jul 4, 2017 at 3:20 AM, Nathan Cutler ***@***.***> wrote:
@mattbenjamin <https://github.com/mattbenjamin> In the end I merged this
PR into #13871 <#13871>. The two commits
that had conflicts (which you resolved) no longer conflicted when I
cherry-picked them on top of the commits already in that PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13841 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AASY58wgS5E_-3U23JtTbIbN_ZK21DRRks5sKeengaJpZM4MWB6D>
.
|
http://tracker.ceph.com/issues/19144
http://tracker.ceph.com/issues/19723
http://tracker.ceph.com/issues/20195