The workaround for the DHT requirement for a lookup on /
needs to be done only once when the xlator graph is inited.
Doing it on every path's lookup results in a major performance
penalty when using distribute subvolumes upwards of 16, as reported
by Avati.

Ref: bug 152

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

BUG: 152 (libglusterfsclient: DHT workaround is a major performance bottleneck)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=152

There is a mechanism for caching the inode numbers got from a lookup
and a struct stat got from a stat or fstat but I wasnt sure if it worked.
This commit simplifies cache updates and checks and the accompanying
tests have made sure that the cache does work.

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

In __do_path_resolve, we need to use the new_loc.path as the input
for resolution rather than the resolved variable, simply because we're
not interested in resolving the names that have been resolved, as
pointed out by the variable name 'resolved'. Instead, we need to resolve
new_loc, which stores the next component in the path to
be looked up.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

The gf_log message actually assumes that loc->name will have a valid
non-NULL name in it, whereas if the loc_t being passed to it was
actually created on a function stack, i.e. a local function variable
and was then passed down the code path to do_path_resolve without ever
initing it or zeroing the structure, its possible that the name member
has a non-NULL but corrupted address. This leads to a segfault.
Whereas, we know loc->path will always have the full path.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

This strcmp existed because of assumptions that do
not hold true since the change in libglusterfsclient
internals recently.

This is another step in fixing the seg-fault on glusterfs_create.
Patch adapted from Raghu's original fix to the problem.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

The earlier case was that the explicit lookups to the server
were being sent only when the parent inode was NULL. This situation
breaks when the parent inode is available in the i- or d-cache
but the child dirent is not. In such a case, no explicit lookups
were being sent to get the missing child dirent.

Now, explicit path lookup happens even if the inode for parent or basename
is not found in the caches.

This also fixes a seg-fault occuring during glusterfs_open, in my test
case, but one that could occur almost anywhere lookup code is used.
Patch adapted from Raghu's original patch.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

- add argument lookup_basename to __do_path_resolve which indicates whether to
    lookup basename(path). This is necessary for apis like glusterfs_get, which
    dont want basename(path) to be looked up by libgf_client_lookup_path.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

- this simplifies the resolution of path to inode, the apis which receive
     path as argument just need to call libgf_client_path_lookup for
     path->inode translation.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

- remove redundent lookups happening in glusterfs_get.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>