[Gluster-devel] RFC/Review: libgfapi object handle based extensions
srangana at redhat.com
Mon Sep 23 05:03:55 UTC 2013
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/
----- Original Message -----
> From: "Anand Avati" <avati at gluster.org>
> To: "Shyamsundar Ranganathan" <srangana at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at nongnu.org>
> 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 <
> 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)
More information about the Gluster-devel