glusterfs.git/xlators/mount/fuse/src, branch v3.10.10

mount/fuse: use fstat in getattr implementation if any opened fd is available

2018-01-03T14:54:19+00:00

The restriction of using fds opened by the same Pid means fds cannot
be shared across threads of multithreaded application. Note that fops
from kernel have different Pid for different threads. Imagine
following sequence of operations:

* Turn off performance.open-behind
* Thread t1 opens an fd - fd1 - on file "file". Let's assume nodeid of
  "file" is "nodeid-file".
* Thread t2 does RENAME ("newfile", "file"). Let's assume nodeid of
  "newfile" as "nodeid-newfile".
* t2 proceeds to do fstat (fd1)

The above set of operations can sometimes result in ESTALE/ENOENT
errors. RENAME overwrites "file" with "newfile" changing its nodeid
from "nodeid-file" to "nodeid-newfile" and post RENAME, "nodeid-file" is
removed from the backend. If fstat carries nodeid-file as argument,
which can happen if lookup has not refreshed the nodeid of "file" and
since t2 doesn't have an fd opened, fuse_getattr_resume uses STAT
which will fail as "nodeid-file" no longer exists.

Since the above set of operations and sharing of fds across
multiple threads are valid, this is a bug.

The fix is to use any fd opened on the inode. In this specific example
fuse_getattr_resume will find fd1 and winds down the call as fstat
(fd1) which won't fail.

Cross-checked with "Miklos Szeredi"  for
any security issues with this solution and he approves the solution.

Thanks to "Miklos Szeredi"  for all the
pointers and discussions.

>Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c
>BUG: 1510401
>Signed-off-by: Raghavendra G 

(cherry picked from commit 8b57378e5596f287a7b9d106dd6fb56a624b42ee)
Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c
BUG: 1529086
Signed-off-by: Raghavendra G

Revert "mount/fuse: report ESTALE as ENOENT"

2018-01-02T16:21:38+00:00

This reverts commit 26d16b90ec7f8acbe07e56e8fe1baf9c9fa1519e.

Consider rename (index.new, store.idx) and open (store.idx) being
executed in parallel. When we break down operations following sequence
is possible.

* lookup (store.idx) - as part of open(store.idx) returns gfid1 as the
  result.
* rename (index.new, store.idx) changes gfid of store.idx to
  gfid2. Note that gfid2 was the nodeid of index.new. Since rename is
  successful, gfid2 is associated with store.idx.
* open (store.idx) resumes and issues open fop to glusterfs with
  gfid1. open in glusterfs fails as gfid1 doesn't exist and the error
  returned by glusterfs to kernel-fuse is ENOENT.
* kernel passes back the same error to application as a result to
  open.

This error could've been prevented if kernel retries open with
gfid2. Interestingly kernel do retry open when it receives ESTALE
error. Even though failure to find gfid resulted in ESTALE error,
commit 26d16b90ec7f8acb converted that error to ENOENT while sending
an error reply to kernel. This prevented kernel from retrying open
resulting in error.

>Change-Id: I2e752ca60dd8af1b989dd1d29c7b002ee58440b4
>BUG: 1500269
>Signed-off-by: Raghavendra G 

(cherry picked from commit 019a55e708375d2b1e576fcc948a691bcdc5c749)
Change-Id: I2e752ca60dd8af1b989dd1d29c7b002ee58440b4
BUG: 1529089
Signed-off-by: Raghavendra G

mount/fuse: never fail open(dir) with ENOENT

2018-01-02T16:20:39+00:00

open(dir) being an operation on inode should never fail with
ENOENT. If gfid is not present, the appropriate error is ESTALE. This
will enable kernel to retry open after a revalidate lookup.

>Change-Id: I8d07d2ebb5a0da6c3ea478317442cb42f1797a4b
>BUG: 1500269
>Signed-off-by: Raghavendra G 

(cherry picked from commit fb4b914ce84bc83a5f418719c5ba7c25689a9251)
Change-Id: I8d07d2ebb5a0da6c3ea478317442cb42f1797a4b
BUG: 1529089
Signed-off-by: Raghavendra G

mount/fuse: Make event-history feature configurable

2017-10-02T12:41:57+00:00

... and disable it by default.

        Backport of:
        > Change-Id: Ia533788d309c78688a315dc8cd04d30fad9e9485
        > Reviewed-on: https://review.gluster.org/18242
        > BUG: 1467614
        > cherry-picked from commit 956d43d6e89d40ee683547003b876f1f456f03b6

This is because having it disabled seems to improve performance.
This could be due to the lock contention by the different epoll threads
on the circular buff lock in the fop cbks just before writing their response
to /dev/fuse.

Just to provide some data - wrt ovirt-gluster hyperconverged
environment, I saw an increase in IOPs by 12K with event-history
disabled for randrom read workload.

Usage:
mount -t glusterfs -o event-history=on $HOSTNAME:$VOLNAME $MOUNTPOINT
OR
glusterfs --event-history=on --volfile-server=$HOSTNAME --volfile-id=$VOLNAME $MOUNTPOINT

Change-Id: Ia533788d309c78688a315dc8cd04d30fad9e9485
BUG: 1495430
Signed-off-by: Krutika Dhananjay

fuse: memory leak fixes

2017-07-19T21:33:34+00:00

Fix fuse ctx memory leak in case an error occurs and the cleanup path
is different than usual. Also fix a memory leak in logging if
eh_save_history() fails.

Cherry picked from commit 5ee383fed9f6408d303aa539dda071275021f8e4:
> Change-Id: I7ec967c807b0ed91184e5b958be70702215c46c9
> BUG: 1470220
> Signed-off-by: Danny Couture 
> Reviewed-on: https://review.gluster.org/17759
> Reviewed-by: Niels de Vos 
> Smoke: Gluster Build System 
> Reviewed-by: N Balachandran 
> Reviewed-by: Prashanth Pai 
> Reviewed-by: Amar Tumballi 
> Tested-by: Amar Tumballi 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Raghavendra G 

Change-Id: I7ec967c807b0ed91184e5b958be70702215c46c9
BUG: 1471028
Signed-off-by: Niels de Vos 
Reviewed-on: https://review.gluster.org/17758
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System

core: run many bricks within one glusterfsd process

2017-02-02T00:54:58+00:00

This patch adds support for multiple brick translator stacks running in
a single brick server process.  This reduces our per-brick memory usage
by approximately 3x, and our appetite for TCP ports even more.  It also
creates potential to avoid process/thread thrashing, and to improve QoS
by scheduling more carefully across the bricks, but realizing that
potential will require further work.

Multiplexing is controlled by the "cluster.brick-multiplex" global
option.  By default it's off, and bricks are started in separate
processes as before.  If multiplexing is enabled, then *compatible*
bricks (mostly those with the same transport options) will be started in
the same process.

Backport of:
> Change-Id: I45059454e51d6f4cbb29a4953359c09a408695cb
> BUG: 1385758
> Reviewed-on: https://review.gluster.org/14763

Change-Id: I4bce9080f6c93d50171823298fdf920258317ee8
BUG: 1418091
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16496
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

fuse: Fix a possible resource leak under GF_SOLARIS_HOST_OS

2017-01-17T20:53:35+00:00

in fuse-helpers.c

Change-Id: Ie367a6dec2a0d5848631b19ebbe39ceafa954a60
BUG: 1412918
Signed-off-by: Saurabh Badhwar 
Reviewed-on: http://review.gluster.org/16395
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Saravanakumar Arumugam 
CentOS-regression: Gluster Build System 
Reviewed-by: Vijay Bellur

fuse: fix memory leak in setxattr

2017-01-12T19:03:09+00:00

If there's some failed check in setxattr of mount/fuse before
actually starting the operation, a fuse_state_t structure is
leaked.

This fix correctly releases allocated resources in case of
error.

Change-Id: I8b1cda67a613c13b6bc38947352e2ccfccf96a1d
BUG: 1412174
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/16380
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Niels de Vos 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

mount/fuse: Fix the place where graph-switch event is logged

2017-01-05T06:07:53+00:00

Change-Id: I3c8577b87db02a2a6ce6159e7d04cf58a2bda0c1
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/16302
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Raghavendra G

fuse: fix fuse dumping for FUSE_WRITE

2016-09-23T05:34:05+00:00

Data coming with FUSE_WRITE requests are arranged
with a special alignment, cf. 15d85ff1. fuse_dumper()
was not aware of this and didn't dump the proper
reqion for FUSE_WRITE.

BUG: 1377427
Signed-off-by: Csaba Henk 
Change-Id: I36255ca3336e95be6e2d256c8199761ddec41869
Reviewed-on: http://review.gluster.org/15525
Smoke: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System