glusterfs.git/xlators/mount, branch v3.7.5

fuse: add "resolve-gids" mount option to overcome 32-groups limit

2015-09-28T09:51:08+00:00

Add a --resolve-gids commandline option to the glusterfs binary. This
option gets set when executing "mount -t glusterfs -o resolve-gids ...".

This option is most useful in combination with the "acl" mount option.
POSIX ACL permission checking is done on the FUSE-client side to improve
performance (in addition to the checking on the bricks).

The fuse-bridge reads /proc/$PID/status by default, and this file
contains maximum 32 groups. Any local (client-side) permission checking
that requires more than the first 32 groups will fail.

By enabling the "resolve-gids" option, the fuse-bridge will call
getgrouplist() to retrieve all the groups from the user accessing the
mountpoint. This is comparable to how "nfs.server-aux-gids" works.

Note that when a user belongs to more than ~93 groups, the volume option
server.manage-gids needs to be enabled too. Without this option, the
RPC-layer will need to reduce the number of groups to make them fit in
the RPC-header.

Cherry picked from commit 64a5bf3749c67fcc00773a2716d0c7b61b0b4417:
> Change-Id: I7ede90d0e41bcf55755cced5747fa0fb1699edb2
> BUG: 1246275
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/11732
> Tested-by: NetBSD Build System 
> Reviewed-by: Ravishankar N 
> Tested-by: Gluster Build System 
> Reviewed-by: jiffin tony Thottan 
> Reviewed-by: Kaleb KEITHLEY 

Change-Id: I7ede90d0e41bcf55755cced5747fa0fb1699edb2
BUG: 1246397
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/11875
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

mount/fuse: Log ENODATA as DEBUG in {f}removexattr

2015-09-03T10:59:49+00:00

Logging ENODATA errors for {f}removexattr at a higher loglevel does not
add a lot of value and causes a log message flood as per multiple reports.

Added a new cbk, fuse_removexattr_cbk() to be used with removexattr fops.
ENODATA now gets logged at loglevel DEBUG in fuse_removexattr_cbk(). This also
prevents more conditional checks in the common fuse_err_cbk() callback.

Change-Id: I1585b4d627e0095022016c47d7fd212018a7194b
BUG: 1248941
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/12015
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/12041

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

fuse: squash 64-bit inodes in readdirp when enable-ino32 is set

2015-06-04T23:17:26+00:00

The structures returned by readdirp contain the inode 2x. Only one of
them was squashed into 32-bits when enable-ino32 is enabled.

Backport of:
> Change-Id: I33a6d28fb118bb23971f918ffeb983d7f033106e
> BUG: 1223889
> Reviewed-on: http://review.gluster.org/10881
> Signed-off-by: Niels de Vos 
> Tested-by: Cyril Peponnet  [on release-3.5]

Change-Id: I33a6d28fb118bb23971f918ffeb983d7f033106e
BUG: 1223890
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/10882
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System

meta: implement fsync(dir)

2015-06-04T11:56:08+00:00

Change-Id: I707c608a9803fe6ef86860ca5578d4d3f63fd2aa
BUG: 1225859
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/10970
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System

protocol: increase default group-cache-timeout to 300 seconds

2015-05-06T17:34:22+00:00

sssd uses 300 seconds by default too. There is no need to overload sssd
with requests that it would have cached.

Cherry picked from commit 34833364e9839f0036bccd58ec0a8a963e69263e:
> BUG: 1215187
> Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/10371
> Tested-by: Gluster Build System 
> Reviewed-by: Kaleb KEITHLEY 
> Reviewed-by: Vijay Bellur 

Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
BUG: 1215189
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/10523
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System
Reviewed-by: Vijay Bellur

geo-rep: Fix ignoring geo-rep safe errors

2015-05-05T06:15:21+00:00

Fix ignoring geo-rep safe errors in fuse layer
and also ignore logging in client translator
for mknod. Though it is rare, to happen with
mknod, it might happen with history crawl on
overlapping changelogs replay.

BUG: 1217938
Change-Id: If06f7a6b6f86a315b4e033e294d6f6be67135cb8
Signed-off-by: Kotresh HR 
Reviewed-on: http://review.gluster.org/10422
Reviewed-on: http://review.gluster.org/10533
Reviewed-by: Aravinda VK 
Tested-by: NetBSD Build System
Tested-by: Gluster Build System

geo-rep: Don't log geo-rep safe errors in mount logs

2015-05-04T13:29:57+00:00

EEXIST and ENOENT are safe errors for geo-replication.
Since mkdir is captured in all the bricks of the changelog.
mkdir is tried multiple times as per the number of bricks.
The first one to process by gsyncd will succeed and all
others will get EEXIST.  Hence EEXIST is a safe error
and can be ignored. Similarly ENOENT also in rm -rf case.
And also gsyncd validates these errors and log them in
master if it is genuine error. This is up with
the patch http://review.gluster.org/#/c/10048/
Hence ignoring above said safe errors.

BUG: 1217938
Change-Id: I1962a85f23fe5e30448ceec1b6ddcb5724ed5627
Signed-off-by: Kotresh HR 
Reviewed-on: http://review.gluster.org/10184
Reviewed-on: http://review.gluster.org/10501
Tested-by: Gluster Build System 
Reviewed-by: Aravinda VK

build: make contrib/uuid dependency optional

2015-04-10T11:39:52+00:00

On Linux systems we should use the libuuid from the distribution and not
bundle and statically link the contrib/uuid/ bits.

libglusterfs/src/compat-uuid.h has been introduced and should become an
abstraction layer for different UUID APIs. Non-Linux operating systems
should implement their compatibility layer there.

Once all operating systems have an implementation in compat-uuid.h, we
can remove contrib/uuid/ from the repository completely.

Change-Id: I345e5357644be2521685e00358bb8c83c4ea0577
BUG: 1206587
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/10129
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

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