glusterfs.git/xlators/mount/fuse/src/fuse-resolve.c, branch v3.6.0alpha1

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

user servicable snapshots

2014-05-29T16:25:46+00:00

Change-Id: Idbf27dbe088e646a8ab81cedc5818413795895ea
Signed-off-by: Raghavendra Bhat 
Signed-off-by: Anand Subramanian 
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/7700
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

fuse-resolve: loc_wipe() after inode_link()

2014-04-21T01:07:11+00:00

the inode to be linked may have the last ref. loc_wipe() can
destroy it before inode_link() gets to ref it.

Change-Id: Ic2d44084e6e9c8289f35cae82c8e4575af105398
BUG: 1089216
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/7505
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

mount/fuse: Fix the NULL dereference errors reported by coverity.

2014-02-18T04:50:56+00:00

Change-Id: I9df57e11b115d7323931735c86b586c0b65fa414
BUG: 789278
Signed-off-by: Poornima 
Reviewed-on: http://review.gluster.org/6990
Reviewed-by: Vijay Bellur 
Tested-by: Gluster Build System

mount/fuse: perform lookup() on inodes linked through readdirplus

2013-08-23T19:09:58+00:00

Some xlators still require lookup() fop to be sent for proper working.
This patch remembers inodes which have been linked through readdiprlus
and makes the resolver send lookups on them.

Change-Id: Ibe8a04a659539d90dfc794521b51bf2bda017a0b
BUG: 979910
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5267
Reviewed-by: Amar Tumballi 
Tested-by: Gluster Build System

fuse-bridge: fix posix-only configuration

2012-11-19T09:17:47+00:00

Recent changes in fuse-resolver had broken the use case of having
a trivial configuration with only storage/posix translator. Fix
it and include a regression test to avoid breakage in the future.

Change-Id: I85cbcac4b5c2d3517dd03fd3dc6d07610697981b
BUG: 868478
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/4114
Tested-by: Gluster Build System 
Reviewed-by: Brian Foster 
Reviewed-by: Vijay Bellur

fuse: create a new fd during fd-migration.

2012-10-02T21:18:14+00:00

Migration of fd to new graph involves creation of a new fd
to be used only for calls sent in that graph.

Earlier approach of using same fd across all graphs, with the
associated inode always guaranteed to be the one valid in
currently active graph, had issues because of the broken
immutability of the association of fd with an inode
(for the life of fd).

With this patch, there will be a basefd, which the kernel will be
aware of. This basefd, contains a mapping of an fd which is valid
in currently active graph.

Signed-off-by: Raghavendra G 
Change-Id: I2b459f05bc2690a66498be107fad6444e3158138
BUG: 802414
Reviewed-on: http://review.gluster.org/3566
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

All: License message change

2012-09-13T20:19:37+00:00

License message changed for server-side, dual license GPLV2 and LGPLv3+.

Change-Id: Ia9e53061b9d2df3b3ef3bc9778dceff77db46a09
BUG: 852318
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/3940
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Anand Avati

All: License message change

2012-08-28T10:45:06+00:00

The license message is changed to
  Copyright (c) 2008-2012 Red Hat, Inc. 
  This file is part of GlusterFS.

  This file is licensed to you under your choice of the GNU Lesser
  General Public License, version 3 or any later version (LGPLv3 or
  later), or the GNU General Public License, version 2 (GPLv2), in all
  cases as published by the Free Software Foundation.

Change-Id: I07d2b63ed5fbbbd1884f1e74f2dd56013d15b0f4
BUG: 852318
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/3858
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

mount/fuse: ignore any erros that might've happened while resolving entry in resolver.

2012-08-03T08:13:36+00:00

One error we hit was absence of gfid on backend. While the lookup
code-path generates a new uuid and sets it on file, resolver code
doesn't do that. Since, functionally (atleast after resolving parent
inode, we would be resolving the path in new-graph) both resolver
and lookup does same work, it would be no harm in ignoring errors
during resolving the entry. This would help us to continue with
the _extra_ work (like healing gfid as of now) in fuse_lookup_resume.

Change-Id: If46d5e07c32e67b5744287a6ef55d0b0fe347689
BUG: 821138
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.com/3344
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati