glusterfs.git/xlators/mount/fuse/src/fuse-resolve.c, branch v3.7.7

all: reduce "inline" usage

2016-01-18T09:02:34+00:00

There are three kinds of inline functions: plain inline, extern inline,
and static inline.  All three have been removed from .c files, except
those in "contrib" which aren't our problem.  Inlines in .h files, which
are overwhelmingly "static inline" already, have generally been left
alone.  Over time we should be able to "lower" these into .c files, but
that has to be done in a case-by-case fashion requiring more manual
effort.  This part was easy to do automatically without (as far as I can
tell) any ill effect.

In the process, several pieces of dead code were flagged by the
compiler, and were removed.

backport of Change-Id: I56a5e614735c9e0a6ee420dab949eac22e25c155,
http://review.gluster.org/11769, BUG: 1245331

Change-Id: Iba1efb0bc578ea4a5e9bf76b7bd93dc1be9eba44
BUG: 1283302
Signed-off-by: Kaleb S KEITHLEY 
Reviewed-on: http://review.gluster.org/12646
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Niels de Vos

Revert "fuse: resolve complete path after a graph switch"

2015-11-09T10:50:53+00:00

back port of http://review.gluster.org/#/c/12375/

This reverts commit d0edb6d555d687f76837515207b9408be0bdd55e.
The same functionality will be provided in a different patch

Change-Id: I33538fa159b375a4662eb05ad4f7604458a8ec2b
BUG: 1279095
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/12537
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: N Balachandran 
Reviewed-by: Raghavendra G

fuse: resolve complete path after a graph switch

2015-10-08T16:13:35+00:00

If a graph switch has happended as part of a attach-tier,
then there is a chance to hash fops to newly added brick
before fix-layout. This causes on going i/o to fail.

This patch will resolve a path, for graph switch by sending
recursive lookup to the parent directories. Those lookups
will help to heal the directory.

backport of>
>Change-Id: Ia2bb4b43a21e5cc6875ba1205628744c3f0ce4e5
>BUG: 1263549
>Signed-off-by: Mohammed Rafi KC 
>Reviewed-on: http://review.gluster.org/12184
>Tested-by: NetBSD Build System 
>Tested-by: Dan Lambright 
>Reviewed-by: Dan Lambright 

(cherry picked from commit d0edb6d555d687f76837515207b9408be0bdd55e)

Change-Id: Ie92cecd5e77178d227ef21242cd0e1af0fe9ee72
BUG: 1259081
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/12319
Tested-by: NetBSD Build System 
Reviewed-by: Dan Lambright 
Tested-by: Dan Lambright

libgfapi: send explicit lookups on inodes linked in readdirp

2015-07-06T15:14:02+00:00

          Backport of http://review.gluster.org/11236

If the inode is linked via readdirp, then the consuners of gfapi which are using
handles (got either in lookup or readdirp) might not send an explicit lookup on
that object again (ex: NFS, samba, USS). If there is a replicate volume where
the replicas of the object are not in sync, then readdirp followed by fops might
lead data being served from the subvolume which is not in sync with latest
data. And since lookup is needed to trigger self-heal on that object the
consumers might keep getting wrong data until an explicit lookup is not done.

Fuse handles this situation by sending an explicit lookup by itself (fuse
xlator) on those inodes which are linked via readdirp, whenever a fop comes on
that inode.

The same procedure is done in gfapi as well to address this situation.

Thanks to shyam(srangana@redhat.com) for valuable inputs

Change-Id: I4230fae8e0b01a95c056282b08ed30832d4804a7
BUG: 1240190
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11545
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Niels de Vos

Avoid conflict between contrib/uuid and system uuid

2015-04-04T17:48:35+00:00

glusterfs relies on Linux uuid implementation, which
API is incompatible with most other systems's uuid. As
a result, libglusterfs has to embed contrib/uuid,
which is the Linux implementation, on non Linux systems.
This implementation is incompatible with systtem's
built in, but the symbols have the same names.

Usually this is not a problem because when we link
with -lglusterfs, libc's symbols are trumped. However
there is a problem when a program not linked with
-lglusterfs will dlopen() glusterfs component. In
such a case, libc's uuid implementation is already
loaded in the calling program, and it will be used
instead of libglusterfs's implementation, causing
crashes.

A possible workaround is to use pre-load libglusterfs
in the calling program (using LD_PRELOAD on NetBSD for
instance), but such a mechanism is not portable, nor
is it flexible. A much better approach is to rename
libglusterfs's uuid_* functions to gf_uuid_* to avoid
any possible conflict. This is what this change attempts.

BUG: 1206587
Change-Id: I9ccd3e13afed1c7fc18508e92c7beb0f5d49f31a
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/10017
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

Use common loc-touchup in fuse/server/gfapi

2015-03-08T15:24:39+00:00

Change-Id: Id41fb29480bb6d22c34469339163da05b98c1a98
BUG: 1115907
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8226
Reviewed-by: Shyamsundar Ranganathan 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Vijay Bellur

mount/fuse: Handle fd resolution failures

2014-08-25T16:00:56+00:00

Problem:
Even when the fd resolution failed, the fop is continuing on the
new graph which may not have valid inode. This lead to NULL layout
subvols in dht which lead to crash in fsync after graph migration.

Fix:
- Remove resolution error handling in FUSE_FOP as it was only added
  to handle fd migration failures.
- check in fuse_resolve_done for fd resolution failures and fail the
  fop right away.
- loc resolution failures are already handled in the corresponding
  fops.
- Return errno from state->resolve.op_errno in resume functions.
- Send error to fuse on frame allocation failures.
- Removed unused variable state->resolved
- Removed unused macro FUSE_FOP_COOKIE

Change-Id: I479d6e1ff2ca626ad8c8fcb6f293022149474992
BUG: 1126048
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8402
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Reviewed-by: Vijay Bellur

Fix resolution issues across fuse/server/afr

2014-06-14T11:10:06+00:00

Problems with fuse/server:
Fuse loc touch up sets loc->name even when pargfid
is not known. Server lookup does (pargfid, name) based
lookup when name is set ignoring the gfid. Because of this server
resolver finds that the lookup came on (null-pargfid, name) and
fails the lookup with EINVAL.

Fix:
Don't set loc->name in loc_touchup if the pargfid is not known.
Did the same even for server-resolver

Problem with afr:
Lets say there is a directory hierarchy a/b/c/d on the mount and the
user is cd'ed into the directory. Bring down one of the bricks of replica and
remove all directories/files to simulate disk replacement on that brick. Now
this brick is brought back up. Creates on the cd'ed directory fail with ESTALE.
Basically before sending a create of 'f' inside 'd', fuse sends a lookup to
make sure the file is not present.  On one of the bricks  'd' is present and
'f' is not so it sends ENOENT as response. On the new brick 'd' itself is not
present. So it sends ESTALE. In afr ESTALE is considered to be special errno on
witnessing which lookup has to fail. And ESTALE is given more priority than
ENOENT. Due to these reasons lookup fails with ESTALE rather than ENOENT. Since
lookup didn't fail with ENOENT, 'create' can't be issued so the command is
failed with ESTALE.

Solution:
Afr needs to consider ESTALE errno normally and ENOENT needs to
be given more priority so that operations like create can proceed even when
only one of the brick is up and running. Whenever client xlator identifies
that gfid-changed, it sets that information in lookup xdata. Afr uses this
information to fail the lookup with ESTALE so that top xlator can send
fresh lookup.

Change-Id: Ica6ce01baef08620154050a635e6f97d51029ef6
BUG: 1106408
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8015
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

user servicable snapshots

2014-05-29T16:25:46+00:00

Change-Id: Idbf27dbe088e646a8ab81cedc5818413795895ea
Signed-off-by: Raghavendra Bhat 
Signed-off-by: Anand Subramanian 
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/7700
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

fuse-resolve: loc_wipe() after inode_link()

2014-04-21T01:07:11+00:00

the inode to be linked may have the last ref. loc_wipe() can
destroy it before inode_link() gets to ref it.

Change-Id: Ic2d44084e6e9c8289f35cae82c8e4575af105398
BUG: 1089216
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/7505
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri