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

[Shyamsundar Ranganathan]

Hi Avati/list, 

Made the required changes as per the comments except changing create to mknod. 
My reasoning for the same is that we need to handle create flags, which would 
hence incur a lookup followed by a mknod, and in terms of optimizing fops used 
in the gfapi (in the handle varieties) I think we can stick to create. Are 
there other options that I am missing? 

Also glfs_h_unlink as it stands today (post glfs_resolve_at usage) may need a 
ESTALE handling, thoughts? 

Otherwise all other comments and changes are made in patch set 4 at the same 
review link, http://review.gluster.org/#/c/5936/ 

Shyam 

----- Original Message ----- 

> From: "Anand Avati" <address@hidden>
> To: "Shyamsundar Ranganathan" <address@hidden>
> Cc: "Gluster Devel" <address@hidden>
> Sent: Thursday, September 19, 2013 9:32:52 PM
> Subject: Re: RFC/Review: libgfapi object handle based extensions

> On Thu, Sep 19, 2013 at 5:13 AM, Shyamsundar Ranganathan <
> address@hidden > 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)

> Avati