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

gfapi: glfs_subvol_done should NOT wait for graph migration.

2017-01-02T13:11:40+00:00

In graph_setup function glfs_subvol_done is called which
is executed in an epoll thread. glfs_lock waits on other
thread to finish graph migration. This can lead to dead lock
if we consume all the epoll threads.

In general any call-back function executed in epoll thread
should not call any blocking call which waits on a network
reply either directly or indirectly, e.g. syncop functions
should not be called in these threads.

As a fix we should not wait for migration in the call-back path.

> Reviewed-on: http://review.gluster.org/15913
> NetBSD-regression: NetBSD Build System 
> Smoke: Gluster Build System 
> Reviewed-by: Niels de Vos 
> CentOS-regression: Gluster Build System 
(cherry picked from commit 17d10b42fc4041442e6cd0bfda45944edea498c6)

Change-Id: If96d0689fe1b4d74631e383048cdc30b01690dc2
BUG: 1399915
Signed-off-by: Rajesh Joseph 
Reviewed-on: http://review.gluster.org/15977
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Niels de Vos

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

2016-08-11T08:35:17+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

Change-Id: Ib6ff0565105c5eedb912a43da4017cd413243612
BUG: 1365821
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/15134
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Rajesh Joseph

gfapi: clear loc.gfid when retrying after ESTALE

2016-05-13T05:52:40+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: 1334443
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/14289
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Rajesh Joseph 
CentOS-regression: Gluster Build System

libglusterfs/gfapi: set appropriate errno for inode_link failures

2016-05-11T14:36:18+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: 1335017
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/14288
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

gfapi: send lookup if inode_ctx is not set

2016-01-14T03:27:45+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.

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

libgfapi: send explicit lookups on inodes linked in readdirp

2015-07-02T09:15:54+00:00

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: I64f0591495dddc1dea7f8dc319f2558a7e342871
BUG: 1236009
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11236
Tested-by: NetBSD Build System 
Reviewed-by: Shyamsundar Ranganathan 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

gfapi : symlink resolution for glfs_object

2015-06-28T07:53:13+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.

Change-Id: Ieee645154455a732edfb2c28834021bab4248810
BUG: 1209735
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/11410
Reviewed-by: Niels de Vos 
Reviewed-by: Raghavendra Talur 
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System

build: do not #include "config.h" in each file

2015-05-29T12:43:17+00:00

Instead of including config.h in each file, and have the additional
config.h included from the compiler commandline (-include option).

When a .c file tests for a certain #define, and config.h was not
included, incorrect assumtions were made. With this change, it can not
happen again.

BUG: 1222319
Change-Id: I4f9097b8740b81ecfe8b218d52ca50361f74cb64
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/10808
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Pranith Kumar Karampuri

libgfapi : port gfapi to new logging framework

2015-04-28T12:46:31+00:00

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

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