Thanks for the response. In my case, I am trying to avoid doing the network level lookup - since I use the same resolve only pass a null for the attribute structure - essentially in my case, it is an atomic multiple object read/write so I only want to resolve to the specific bricks and then dispatch the requests in a single rpc. Once the files can be resolved, a single read/write is mostly sent to the back-end. Most places seem to be calling with the attribute structure which translates into a force lookup, is it okay to move the force out of the if-block so it can apply to files that we are not interested in? That way it will help avoid doing the lookups for multiple files. I was curious to know how the inode, table maps to the brick - presently I have 1 brick but planning to play with a couple of bricks - the returned loc has different inodes for each file, and inode table is common - I do see one spurious lookup over the network (eg. I used lookup for 100 files, there was only 1 lookup generated over the network) - with the force, it becomes 100 lookups which simply return that the file does not exist. --Siva On Fri, Nov 21, 2014 at 1:21 PM, RAGHAVENDRA TALUR <raghavendra.talur@xxxxxxxxx> wrote: > Hi Rudra, > > The inode and inode table data structures here represent the in-memory inode > on the client side.(gfapi) > > When we are trying to create a new file, it becomes > *necessary* that we confirm with the backend if it can be created, hence > a force lookup. > > Only case where we avoid a force lookup is when in-memory inode is > present(means we had resolved this recently and have all the stat data) > and it is not the last component in the path. Say "b" in the path "/a/b/c". > > Please do tell if that does not clarify your question. > > Raghavendra Talur > > > On Fri, Nov 21, 2014 at 5:50 PM, Rudra Siva <rudrasiva11@xxxxxxxxx> wrote: >> >> Hi, >> >> A new file create does not honour the force lookup avoidance - in my >> case I am not interested in the attributes or forcing a lookup, just >> need the inode details - is there a specific reason why !force_lookup >> is not outside the block? >> >> https://github.com/gluster/glusterfs/blob/master/api/src/glfs-resolve.c >> >> 270: if (!force_lookup) { >> >> suggested fix: >> >> move this to outside of if-else to line 296 - so it applies to >> existing as well as new files. >> >> Can someone explain what do the inode and inode table data structures >> represent? >> -- >> -Siva >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@xxxxxxxxxxx >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel > > > > > -- > Raghavendra Talur > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
