glusterfs.git/xlators/nfs/server/src/nfs3.h, branch v3.4.0alpha

ACLv3 - Access Control Lists V3

2012-11-14T07:24:46+00:00

Change-Id: I43e544d6cdeac5e3880141477461e7c22cbf6e91
BUG: 847622
Signed-off-by: Krishna Srinivas 
Reviewed-on: http://review.gluster.org/4045
Reviewed-by: Kaleb KEITHLEY 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

nfs/nlm: procedures for PC clients

2012-05-17T09:12:49+00:00

*  This change introduces four NLMv4 procedures:

   NM_LOCK, SHARE, UNSHARE and FREE_ALL.

   These are used by PC clients (windows/dos) to control access
   to files.

   1. NM_LOCK: this lock is not monitored by statd.

   2. SHARE: A share reservation is a lock on the whole file
      that is taken whenever a file is opened on windows clients.
      This has ACCESS (N, R, W, RW) and DENY MODE (N, R, W, RW).
        ACCESS:    mode of access requested by the client;
        DENY MODE: what the requesting client wants to
                   deny other clients.

   3. UNSHARE: remove a share reservation obtained by SHARE.
      Called while closing a file.

   4. FREE_ALL: remove all share reservations and locks,
      both monitored and unmonitored, of the calling client.

*  lock and nm_lock use a common function with only
   a flag conveying whether or not to monitor a lock.

*  NOTES:
   1. SHARE reservations are not STACK_WIND'd to subsequent xlators.
      These are maintained in-memory in the nfs xlator.

   2. Consequently, for SHARE reservations to work effectively,
      all PC clients  *must* mount from the same gNfs server.
      Not doing so will result in different servers maintaining
      separate SHARE reservations which will not be enforced
      for obvious reasons.

Change-Id: Id4f22670a94ed58691a6a7f4c80aa8c11421a277
BUG: 800287
Signed-off-by: Rajesh Amaravathi 
Reviewed-on: http://review.gluster.com/3212
Tested-by: Gluster Build System 
Reviewed-by: Krishna Srinivas

glusterd: Include port in nfs status

2012-04-02T09:41:18+00:00

Change-Id: I679e491e801b694e8a0f93dd87cf540441dae927
BUG: 806877
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.com/3060
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

NLM - Network Lock Manger V4

2012-02-20T15:26:51+00:00

Change-Id: Ic31b8bb10a28408da2a623f4ecc0c60af01c64af
BUG: 795421
Signed-off-by: Krishna Srinivas 
Reviewed-on: http://review.gluster.com/2711
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

nfs: changes for using nameless lookup and anonymous FDs

2012-01-20T13:06:15+00:00

- Use gfid to create filehandle instead of encoding path components
- Utilize nameless lookups of GFID for deep resolution instead of
  crawling the namespace with component hints
- Use anonymous FDs for file based operations
- Do away with fdcaching code for files and dirs

Change-Id: Ic48fb23370b25d183f7e1fc1cc5dffa9d5bab3fb
BUG: 781318
Reviewed-on: http://review.gluster.com/2645
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

nfs3: Resolve entry vs. hash conflict at same dir depth

2011-09-08T06:53:44+00:00

Intro Note
==========
The current code in hard fh resolution takes the first-match approach, i.e.
which ever dirent either matches the hash or matches the gfid first
is the one chosen as the result for the next step of fh resolution. In
the latter case, i.e., dirent matches the gfid, we the next step is to
conclude the fh resolution by returning the entry whose gfid matched.
In the former, i.e., the hash matches the dirent, we choose the hash-matching
dirent as the next directory to descend into, for searching the file to be
operated upon.

Problem
=======
When performing hard fh resolution, there can be a situation where:

o the hash of the primary entry,i.e. the entry we're looking for and the hash
of another sibling directory, match. Note the use of "sibling", meaning both
the primary entry and the hash matching one are in the same directory, i.e.,
their filehandle.hashcount will be same.

o the sibling directory is encountered first during the dir search.

Because of the current code described in "Intro", we'll end up descending into
the sibling directory even though the correct behaviour is to ignore this and
wait till we encounter the primary entry in the same parent directory.

Once we end up descending into this sibling directory, the directory depth
validation check fails. The check fails because it notices that the resolution
is attempting to open a directory that is deeper in the fs tree than the file
we're looking for. When this check fails, we return an ESTALE. So basically, a
false-positive results in an estale to Specsfs.

This is not a theoretical situation. Me and Avati saw this on specsfs test
where sfs created terabytes-sized file system for its tests. The number of
files was so huge in a single directory that the hashes of two entries ended up
colliding.

Change-Id: I4a6df11d326a67a507b1cd716c2c8e00b5a858a4
BUG: 3510
Reviewed-on: http://review.gluster.com/357
Tested-by: Gluster Build System 
Reviewed-by: Shehjar Tikoo

Change Copyright current year

2011-08-10T17:57:19+00:00

Change-Id: I2d10f2be44f518f496427f257988f1858e888084
BUG: 3348
Reviewed-on: http://review.gluster.com/200
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

LICENSE: s/GNU Affero General Public/GNU General Public/

2011-08-06T13:33:52+00:00

Change-Id: I3914467611e573cccee0d22df93920cf1b2eb79f
BUG: 3348
Reviewed-on: http://review.gluster.com/182
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

RPC unify code change

2011-07-29T10:37:07+00:00

Change-Id: Ibe18a2a63fd023ac57652c4dfc8ac8a69d983b83
BUG: 3112
Signed-off-by: krishna 
Reviewed-on: http://review.gluster.com/116
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

nfs3: Force root lookup before starting fh resolution

2010-12-29T18:20:50+00:00

Signed-off-by: Shehjar Tikoo 
Signed-off-by: Anand V. Avati 

BUG: 2200 (cp dies with "Invalid argument" after failover)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=2200