glusterfs.git/api, branch v3.8rc1

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: Fix a deadlock caused by graph switch while aio in progress

2016-05-06T14:23:51+00:00

RCA:
Currently async nature is achieved by submitting a syncop operation to
synctask threads. Consider a scenario where the graph switch is triggered,
the next write fop checks for the next available graph and sets
fs->migration_in_progess and triggers the migration of fds and other
things, which can cause some syncop_lookup operation. While this fop (on
synctask thread) is waiting for syncop_lookup to return, lets say there
are another 17 write async calls submitted, all these writes are blocked
waiting for fs->migration_in_progress to be unset, hence all the 16
synctask threads are blocked waiting for fs->migration_in_progress to be
unset. Now the syncop_lookup returns, but there are no synctask threads to
process the lookup_cbk. If this syncop_lookup doesn't return,
then fs->migration_in_progress can not be unset by the first fop.
Thus causing a deadlock.

To fix this deadlock, changing all the async APIs to use STACK_WIND,
instead of syntask to achieve async nature. glfs_preadv_async is already
implemented using STACK_WIND, now changing all the other async APIs
also to do the same.

This patch as such will not reduce the performance of async IO, the only
thing that can affect is that, in case of write, the buf passed by
application is copied onto iobuf in the same thread wheras before it
was being copied in synctask thread.

Since, the syncop + graph switch logic (lock across fops) is not a good
candidate for synctask, changing the async APIs to use STACK_WIND

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

Change-Id: Idf665cae0a8e27697fbfc5ec8d93a6d6bae3a4f1
BUG: 1333266
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/14221
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Niels de Vos

gfapi: fill iatt in readdirp_cbk if entry->inode is null

2016-04-28T19:53:41+00:00

If any of dirent have inode as null in readdirp_cbk, which indicates
that the stat information is not valid. So for such entries, we send
explicit lookup to fill the stat information.

Change-Id: I0604bce34583db0bb04b5aae8933766201c6ddad
BUG: 1330567
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/14079
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Niels de Vos

gfapi: set need_lookup flag on response list

2016-04-27T14:26:44+00:00

We set need_lookup flag for entries returned by readdirp
to force lookup. Currently we are setting on the previously
stored list, rather than response list returned by readdirp.

This patch will iterate over current list returned by readdirp
and will set need_lookup flag.

Change-Id: Ibd6fcbc188f4c87f40ece7a9dcda27645401c240
BUG: 1330476
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/14073
NetBSD-regression: NetBSD Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Rajesh Joseph 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System

glfs-mgmt: fix connecting to multiple volfile transports

2016-03-24T15:08:07+00:00

Problem:
[
        {"host":"1.2.3.4", "port":"24007", "transport":"tcp"},
        {"host":"/var/run/glusterd.socket", "transport":"unix"}
]

Consider the above case where we have two volfile servers, each
has different transport type, we first try to connect to server1
which has transport type "tcp" let's say we found that host address
is invalid, now we pick the next available server2, in our case
it is of type "unix" and try to connect to it.

but we fail to connect to it even we have right unix path, because
multiple volfile servers with different transport type is not taken
care currently.

Solution:
Every time we receive a  RPC_CLNT_DISCONNECT event in mgmt_rpc_notify,
we need to check the transport type of the volfile server in the list
and set the keys "transport.socket.connect-path" or "remote-host"
accordingly.

Change-Id: I36bec46ef2e92e4642a7d7d64b423d0bc3ab269b
BUG: 1320489
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/13819
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Tested-by: Prasanna Kumar Kalever 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Jeff Darcy

gfapi: Fix the crashes caused by global_xlator and THIS

2016-03-23T05:47:31+00:00

Issue: http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10922

The right fix for this is elaborate and intrusive, until it is in place,
this patch provides a temperory fix. This fix is necessary, as without this
libgfapi applications like qemu, samba, NFS ganesha are prone to crashes.
This patch will be reverted completely, once the actual fix gets accepted.

Change-Id: Ic975ab0bb03ba415cdf9bddba1534ba4d2d2820c
BUG: 1319374
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/13784
Smoke: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Jeff Darcy 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

gfapi: preserve glfd state during glfs_dup

2016-03-15T06:46:30+00:00

Following patch introduced a new state variable in glfd
to track the current status of the fd.
http://review.gluster.org/13340/

But this state was not copied in glfd_dup function.

BUG: 1311146
Change-Id: I283f8944035f6defe491f81e13d7ef28fc440572
Signed-off-by: Rajesh Joseph 
Reviewed-on: http://review.gluster.org/13666
Smoke: Gluster Build System 
Reviewed-by: Prashanth Pai 
Tested-by: Prashanth Pai 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur 
Reviewed-by: Niels de Vos

gfapi: Use inode_forget in case of handle objects

2016-02-24T02:51:11+00:00

Currently with gfapi, even if applications release their
reference on paritular inode entries, those entries never
get destroyed as they shall always have positive nlookup
count unless inode_table exceeds lru limit.

Since inodes and their contexts can consume considerable
amount of memory, applications may end up consuming lot of
memory and may even get OOM killed.

To avoid that, have considered below approaches (for handle based access)-
a) Do 'inode_lookup' only if the corresponding inode is created
for the first time and forget it during close of the handle

This shall not work as multiple handle objects can refer to
same inode entry and inode_forget from second handle object
onwards shall result in assert.

b) Do 'inode_lookup' during a handle or fd creation

But this approach shall affect the performance of the fops which
operate on neither handle nor fd.

c) current approach taken-
Applications using glfs handle objects hold a reference
on corresponding inode entries. Hence it is safe to forget
those inodes and make nlookup count to '0' while trying to
delete those handle objects. That way the last unref (i.e,
from the last handle close) shall result in inode_destroy().

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

gfapi: Add xlator_cbks fops in gfapi

2016-02-24T00:59:08+00:00

Change-Id: I1fe5dd757e65206f92e0a867b43b49a3c0f2d4cf
BUG: 1311124
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/13499
Smoke: Gluster Build System 
Reviewed-by: Jeff Darcy 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System