You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, zap_remove()/zap_remove_by_dnode() needs to lookup the specified index (or name) to locate the entry internally with the directory locked, then remove the found entry. In fact, for most of cases, the caller has already performed lookup before calling zap_remove()/zap_remove_by_dnode(). But related lookup result cannot be used by the zap_remove()/zap_remove_by_dnode().
I am wondering whether or not we can extend related API (and locks) to allow lookup the entry outside and directly use the lookup result for removing, that will save some lookup overhead. That will improve unlink/delete performance, especially for large directory.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.
Currently, zap_remove()/zap_remove_by_dnode() needs to lookup the specified index (or name) to locate the entry internally with the directory locked, then remove the found entry. In fact, for most of cases, the caller has already performed lookup before calling zap_remove()/zap_remove_by_dnode(). But related lookup result cannot be used by the zap_remove()/zap_remove_by_dnode().
I am wondering whether or not we can extend related API (and locks) to allow lookup the entry outside and directly use the lookup result for removing, that will save some lookup overhead. That will improve unlink/delete performance, especially for large directory.
The text was updated successfully, but these errors were encountered: