[Gluster-devel] RFC/Review: libgfapi object handle based extensions

Anand Avati avati at gluster.org
Thu Sep 19 16:02:52 UTC 2013

On Thu, Sep 19, 2013 at 5:13 AM, Shyamsundar Ranganathan <
srangana at redhat.com> wrote:

> Avati,
> Please find the updated patch set for review at gerrit.
> http://review.gluster.org/#/c/5936/
> Changes made to address the points (1) (2) and (3) below. By the usage of
> the suggested glfs_resolve_inode approach.
> I have not yet changes glfs_h_unlink to use the glfs_resolve_at. (more on
> this a little later).
> So currently, the review request is for all APIs other than,
> glfs_h_unlink, glfs_h_extract_gfid, glfs_h_create_from_gfid
> glfs_resolve_at: Using this function the terminal name will be a force
> look up anyway (as force_lookup will be passed as 1 based on
> !next_component). We need to avoid this _extra_ lookup in the unlink case,
> which is why all the inode_grep(s) etc. were added to the glfs_h_lookup in
> the first place.
> Having said the above, we should still leverage glfs_resolve_at anyway, as
> there seem to be other corner cases where the resolved inode and subvol
> maybe from different graphs. So I think I want to modify glfs_resolve_at to
> make a conditional force_lookup, based on iatt being NULL or not. IOW,
> change the call to glfs_resolve_component with the conditional as, (reval
> || (!next_component && iatt)). So that callers that do not want the iatt
> filled, can skip the syncop_lookup.
> Request comments on the glfs_resolve_at proposal.

That should be OK (passing iatt as NULL to skip forced lookup)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130919/1c379abf/attachment-0001.html>

More information about the Gluster-devel mailing list