Repository navigation
Conversation
65532f7 to
63316a1
Compare
Test Results 24 files 24 suites 4d 2h 14m 23s ⏱️ Results for commit b66cf23. ♻️ This comment has been updated with latest results. |
c8d354d to
b39589c
Compare
hahnjo
left a comment
There was a problem hiding this comment.
Some comments inline. I'm wondering about the descriptor guards (which get quite a bit more complicated): when do we need them? A page source should be accessed by at most one thread at a time, no?
The cluster prefetch accesses it in parallel. I think it's worthy seeing if we can collect all the locators to prefetch in the main thread, which indeed would allow for removing the locks altogether. I don't think it would fundamentally change this PR, however. I'd consider the additions to the lock guards mostly mechanical. |
e28913e to
372e990
Compare
f602672 to
55d62e1
Compare
91c5bf3 to
ec1718a
Compare
hahnjo
left a comment
There was a problem hiding this comment.
(didn't click the right button, see #23524 (review))
Factor out loading a page list (and thus populating cluster group details) into a separate method, to be reused later.
... by ensuring cluster details are available when cluster descriptors are requested.
To be called after attach in cases where it is clear upfront that the full information of the cluster details is needed.
With on-demand loading of page lists, the connection to storage (file handle, DAOS container, etc.) can be used concurrently, by the page list loading and by the prefetcher. Hence requires locking.
ec1718a to
b66cf23
Compare
Key feature for huge-file support: don't necessarily load all page list (and thus cluster group details) upfront but allow for them to be loaded on demand.
Follow-up changes to limit the memory footprint of cluster metadata:
FindClusterId()such that in common cases we don't need to do a full binary search butFindClusterId(), which points us directly to the right cluster group