Skip to content
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

Add zap_prefetch() interface #2318

Closed
wants to merge 1 commit into from

Conversation

behlendorf
Copy link
Contributor

Provide a generic interface to prefetch ZAP entries by name. This
function is based of the existing zap_prefetch_uint64() version which
is used by the deduplication code.

Signed-off-by: Brian Behlendorf behlendorf1@llnl.gov

Provide a generic interface to prefetch ZAP entries by name.  This
function is based of the existing zap_prefetch_uint64() version which
is used by the deduplication code.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
@behlendorf behlendorf added this to the 0.6.4 milestone May 9, 2014
@behlendorf behlendorf modified the milestones: 0.6.3, 0.6.4 May 19, 2014
@behlendorf
Copy link
Contributor Author

@prakashsurya Could you please review this. I'd like to merge it to get the ground work in place for potentially improving Lustre's prefetch.

@prakashsurya
Copy link
Member

My only gripe is adding a function without any internal consumers of it, but other than that, LGTM.

Why use MT_EXACT? I'm not too familiar with those flags meaning or usage (apart from looking at zap.h), so I'm curious why that over the others.

@behlendorf
Copy link
Contributor Author

I agree, having an internal consumer would be best. I'm sure there are places where we could call it as a micro-optimization, but it might be difficult to quantify if it actually helps. One place where might help significantly is in zfs_readdir() when you're iterating over a fat zap.

As for MT_EXACT it's the only valid flag which zap_name_alloc() accepts when zp->zap_normflags isn't set. This flags are to handle how a lookup should be normalized.

@behlendorf
Copy link
Contributor Author

I'm bumping this to a future release until we have a known consumer.

@behlendorf behlendorf modified the milestones: 0.7.0, 0.6.3 May 22, 2014
@behlendorf
Copy link
Contributor Author

Closing this issue until we have a known consumer. The patch will remain available if we decide it's needed.

@behlendorf behlendorf closed this Jul 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Feature request or new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants