glusterfs.git/api/src/glfs-resolve.c, branch v3.7.16

gfapi: Fix IO error caused when there is consecutive graph switches

2016-08-25T04:42:50+00:00

Backport of http://review.gluster.org/#/c/14722/

This is part 2 of the fix, the part 1 can be found at:
http://review.gluster.org/#/c/14656/

Problem:
=======
Consider a race between, __glfs_active_subvol() and graph_setup().
Lets say @TIME T1:
fs->active_subvol = A
fs->next_subvol = B
__glfs_active_subvol()                //under lock fs->mutex
{
  ....
  new_subvol = fs->next_subvol       //which is B
  ....                               //Start migration from A to B
  __glfs_first_lookup(){
     ....
     unlock fs->mutex                //@TIME T2
     network fop
     lock fs->mutex
     ....
  }
  ....                                //migration continue on B
  fs->active_subvol = fs->next_subvol //which is C (explained below)
  ....
}

@Time T2, lets say in another thread, graph_setup() is called with C,
note that at T2, fs->mutex is unlocked.

graph_stup(C...)
{
  lock fs->mutex
  ....
  if (fs->next_subvol)                // which is B
      destroy subvol (fs->next_subvol)
  ....
  fs->next_subvol = C
  ....
  unlock fs->mutex
}

Thus at the end of this,
fs->old_subvol = A;
fs->active_subvol = C;
fs->next_subvol = NULL;
which is wrong, as B completed migration, but was destroyed by
graph_setup, and C never was migrated.

Solution:
=========
Any new graph can be in one of the 2 states:
- Picked for migration, migration in progress (fs->mip_subvol)
- Not picked so far for migration (fs->next_subvol)
graph_setup() updates fs->next_subvol only, __glfs_active_subvol()
moves fs->next_subvol to fs->mip_subvol and fs->next_subvol = NULL
atomically, and then once the migration is complete, make that the
fs->active_subvol

> Reviewed-on: http://review.gluster.org/14722
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Raghavendra Talur 
> Reviewed-by: Rajesh Joseph 
> Reviewed-by: Niels de Vos 

BUG: 1367294
Change-Id: Ib6ff0565105c5eedb912a43da4017cd413243612
Signed-off-by: Poornima G 
Signed-off-by: Oleksandr Natalenko 
Reviewed-on: http://review.gluster.org/15167
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kaushal M

gfapi: clear loc.gfid when retrying after ESTALE

2016-05-13T05:52:46+00:00

If an ESTALE is returned as result of a revalidate lookup, it means the
previous gfid and inode are to be discarded and lookup has to be tried
as a fresh one. A fresh lookup should not have loc.gfid set. We were
creating a new inode and passing it down but not clearing loc.gfid.
This patch fixes that.

>Change-Id: Ib192ada0528b5fb5e49b4e2555f2bcab62710e2d
>BUG: 1334444
>Signed-off-by: Raghavendra Talur 
>Reviewed-on: http://review.gluster.org/14274
>Smoke: Gluster Build System 
>NetBSD-regression: NetBSD Build System 
>Reviewed-by: Niels de Vos 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Pranith Kumar Karampuri 
>(cherry picked from commit b2f09e531029f573772a09572cee0f8e1855481b)

Change-Id: Ib192ada0528b5fb5e49b4e2555f2bcab62710e2d
BUG: 1334441
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/14290
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Rajesh Joseph

libglusterfs/gfapi: set appropriate errno for inode_link failures

2016-05-11T14:36:33+00:00

We do not seem to be setting errno appropriately in case
of inode_link failures. This errno may be used by any application
(for eg., nfs-ganesha) to determine the error encountered. This
patch addresses the same.

This is backport of below mainline fix -
        http://review.gluster.org/14278

Change-Id: I674f747c73369d0597a9c463e6ea4c85b9091355
BUG: 1335016
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/14278
Reviewed-by: Niels de Vos 
Reviewed-by: jiffin tony Thottan 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-on: http://review.gluster.org/14287
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

gfapi: send lookup if inode_ctx is not set

2016-02-27T18:49:49+00:00

During resolving of an entry or inode, if inode ctx
was not set, we will send a lookup to pupulate inode
ctx for every xlators

This patch also make sure that inode_ctx will be created
after every inode_link. We will store inode_ctx value as
LOOKUP_NEEDED if the inode is liked via readdirp, in all
other case we will store inode_ctx value as LOOKUP_NOT_NEEDED.

Back port of>
>Change-Id: I3a10c298944200fa3862127187ae8988e582d352
>BUG: 1297311
>Signed-off-by: Mohammed Rafi KC 
>Reviewed-on: http://review.gluster.org/13226
>Reviewed-by: Poornima G 
>Tested-by: NetBSD Build System 
>Reviewed-by: Shyamsundar Ranganathan 
>Reviewed-by: Dan Lambright 
>Tested-by: Dan Lambright 

Change-Id: Ifeabb5611fcaa3c41404f0cdc48a680a16600e68
BUG: 1306131
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/13414
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Poornima G 
Reviewed-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

gfapi : symlink resolution for glfs_object

2015-06-28T07:53:27+00:00

Generally posix expects symlink should be resolved, before performing an
acl related operation. This patch introduces a new api glfs_h_resolve_symlink()
which will do the same.

backport of http://review.gluster.org/#/c/11410/1

>Change-Id: Ieee645154455a732edfb2c28834021bab4248810
>BUG: 1209735
>Signed-off-by: Jiffin Tony Thottan 

Change-Id: I13a83f37a9e59418fd8eb4bf2d44f828515beabf
BUG: 1236269
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/11438
Reviewed-by: Niels de Vos 
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System

libgfapi : port gfapi to new logging framework

2015-05-07T10:30:51+00:00

This also contains backport of http://review.gluster.org/10456:
- Fix ENOKEY build failure on non Linux systems

Cherry picked from commit 8986a47c54db4769feb4e6664532386f1cd0275d:
> Change-Id: Iaa0a92f82b9a0a26eda1a8d72b3b66ce66fab443
> BUG: 1194640
> Signed-off-by: Humble Devassy Chirammal 
> Reviewed-on: http://review.gluster.org/9918
> Tested-by: Gluster Build System 
> Reviewed-by: jiffin tony Thottan 
> Reviewed-by: Raghavendra Talur 
> Reviewed-by: soumya k 
> Reviewed-by: Niels de Vos 

Signed-off-by: Humble Devassy Chirammal 
Change-Id: I320b4f1268d49a1a1086412ff2a9fb815bcf1cf4 
BUG: 1217722
Change-Id: I320b4f1268d49a1a1086412ff2a9fb815bcf1cf4
Reviewed-on: http://review.gluster.org/10486
Tested-by: NetBSD Build System
Reviewed-by: Kaleb KEITHLEY 
Tested-by: Gluster Build System 
Reviewed-by: jiffin tony Thottan

libglusterfs/syncop: Add xdata to all syncop calls

2015-04-08T15:14:59+00:00

This patch adds support for xdata in both the
request and response path of syncops.

Few calls like lookup already had the support;
have renamed variables in few places to maintain
uniformity.

xdata passed downwards is known as xdata_in
and xdata passed upwards is known as xdata_out.

There is an old patch by Jeff Darcy at
http://review.gluster.org/#/c/8769/3 which does the
same for some selected calls. It also brings in
xdata support at gfapi level.

xdata support at gfapi level would be introduced
in subsequent patches.

Change-Id: I340e94ebaf2a38e160e65bc30732e8fe1c532dcc
BUG: 1158621
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/9859
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

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

gfapi: improve source comments and error messages.

2015-03-16T09:49:43+00:00

Change-Id: I0bfa44eb5b5f21e381af3e71c26ea863e4adc46f
BUG:1202274
Signed-off-by: Humble Devassy Chirammal 
Reviewed-on: http://review.gluster.org/9878
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos