glusterfs.git/xlators/protocol/server/src/server-resolve.c, branch v3.7.16

libglusterfs: Negate all but O_DIRECT flag if present on anon fds

2016-06-17T00:21:20+00:00

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

This is to prevent any unforeseen problems that might arise due to
writevs and readvs being wound with @flag parameter containing
O_TRUNC or O_APPEND especially wrt translators like sharding and ec
where O_TRUNC write or O_APPEND write on individual shards/fragments
is not the same as O_TRUNC write or O_APPEND write as expected by the
application.

Change-Id: Ib0110731d6099bc888b7ada552a2abbea8e76051
BUG: 1342903
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/14735
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri 
CentOS-regression: Gluster Build System

core, shard: Make shards inherit main file's O_DIRECT flag if present

2016-06-16T16:04:10+00:00

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

If the application opens a file with O_DIRECT, the shards'
anon fds would also need to inherit the flag. Towards this,
shard xl would be passing the odirect flag in the @flags parameter
to the WRITEV fop. This will be used in anon fd resolution
and subsequent opening by posix xl.

Change-Id: I3a0593fa46cc25e390a5762a0354b469c2a1532d
BUG: 1342903
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/14663
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Jeff Darcy

server: send lookup on root inode when itable is created

2016-03-31T12:15:32+00:00

This is a backport of http://review.gluster.org/#/c/13837

 * xlators like quota, marker, posix_acl can cause problems
   if inode-ctx are not created.
   sometime these xlarors may not get lookup on root inode
   with below cases
   1) client may not send lookup on root inode (like NSR leader)
   2) if the xlators on one of the bricks are not up,
      and client sending lookup during this time: brick
      can miss the lookup
   It is always better to make sure that there is one lookup
   on root. So send a first lookup when the inode table is created

 * When sending lookup on root, new inode is created, we need to
   use itable->root instead

> Change-Id: Iff2eeaa1a89795328833a7761789ef588f11218f
> BUG: 1320818
> Signed-off-by: vmallika 
> Reviewed-on: http://review.gluster.org/13837
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Jeff Darcy 

Change-Id: I0abf45444c21b3bc77b5a75ab9a2049a411048d3
BUG: 1320892
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/13862
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created

2015-08-14T08:12:41+00:00

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

This test sets the lru limit of the inode table to 1 and checks if inode forgets
and resolve cause any problem with bit-rot xattrs (especially bad-file xattr).

Change-Id: I3a19f90384c980368152bb723e7263eab2bed6bd
BUG: 1252348
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11881
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar

protocol/server: use different dict for resolving

2015-07-23T06:46:16+00:00

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

protocol/server has to resolve the inode before continuing with any fop coming
from the clients. For resolving it, server xlator was using the same dict
associated with the fop. It causes problems in some situations.

If a directory's inode was forgotten because of lru limit being exceeded, then
when a create fop comes for an entry within that directory, server tries to
resolve it. But since the parent directory's inode is not found in the inode
table, it tries to do a hard resolve by doing a lookup on the parent gfid.

If any xlator below server wants to get some extended attributes whenever
lookup comes, then they set the new keys in the same dict that came along with
the create fop. Now, the lookup of the parent succeeds and the create fop
proceeds with the same dict (with extra keys present). posix xlaror creates
those xattrs that are present in the dict. Thus the xattrs which were not to
be present by default are also set as part of create. (Ex: bit-rot related
xattrs such as bad-file, version and sign xattrs)

Change-Id: I62b0b012b0af3c92df6fced61f87dd0b6b015d4c
BUG: 1244100
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11703
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

protocol/server : port log messages to a new framework

2015-06-15T05:25:00+00:00

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

Cherry picked from dc089a1a51988c2b407040e1684d7b0adbd79556
> Change-Id: I7901f55d06716161cc31d2b79a600a16b5ec2ef8
> BUG: 1194640
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/9874
> Tested-by: Gluster Build System 
> Reviewed-by: Raghavendra G 

Change-Id: I7901f55d06716161cc31d2b79a600a16b5ec2ef8
BUG: 1217722
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/10552
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

Changing log level from Warning to Debug

2015-06-08T13:21:30+00:00

Change-Id: Ie9bf338802e3f1c59c92d2749a1f8bc745dc5455
BUG: 1228100
Signed-off-by: Ashish Pandey 
Reviewed-on: http://review.gluster.org/10998
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

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

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