glusterfs.git/xlators/nfs/server/src/nfs3-helpers.c, branch v3.3.2qa1

remove code that was part of hard resolution which is not needed anymore.

2012-03-14T18:23:25+00:00

Change-Id: I9321745a40765eff048a656a7885f12847a0a318
BUG: 781318
Signed-off-by: krishna 
Reviewed-on: http://review.gluster.com/2830
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Vijay Bellur

nfs: no need to recalculate the 'ino' from gfid

2012-03-14T10:05:54+00:00

it is guaranteed to be sent properly from posix layer itself now

Change-Id: Ifbbf558f3bcfa609bf107a75c692003ca261ac0a
Signed-off-by: Amar Tumballi 
BUG: 800831
Reviewed-on: http://review.gluster.com/2923
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

nfs/server: allow deletion of files by default

2012-03-10T09:11:31+00:00

this is needed for Micrsoft Windows-based Nfs clients
which do not ignore ACCESS3_DELETE permission not being
granted, while linux/unix systems ignore the same.
behaviour on linux/unix systems remains unchanged

Change-Id: I67f5f66a7486b93163aebedec5fbaa303173964e
BUG: 790781
Signed-off-by: Rajesh Amaravathi 
Reviewed-on: http://review.gluster.com/2875
Tested-by: Gluster Build System 
Reviewed-by: Krishna Srinivas 
Reviewed-by: Vijay Bellur

support for nano second resolution for mtime,ctime,atime attributes.

2012-02-09T15:58:56+00:00

Change-Id: Id5078f270d0fec280b53d4aa7b16bbaf42a2df05
BUG: 784095
Signed-off-by: krishna 
Reviewed-on: http://review.gluster.com/2730
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

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

glusterfs: An effort to fix all the spell mistakes and typo

2011-11-17T05:08:56+00:00

in the entire glusterfs codebase.

This patch fixes many of spell mistakes and typo in the entire
glusterfs codebase and all supported modules.

Change-Id: I83238a41aa08118df3cf4d1d605505dd3cda35a1
BUG: 3809
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.com/731
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Vijay Bellur

NFS: logging enhancement.

2011-11-16T10:05:27+00:00

Change-Id: Ie1731a6b2b63e07bc49a84c2f9dd87c5b50a9f53
BUG: 3527
Reviewed-on: http://review.gluster.com/573
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Vijay Bellur

NFS : Posix compliance fixes.

2011-09-22T11:51:22+00:00

Change-Id: I4f1d8883a3eedee20557e306815674a6dc062bfe
BUG: 1337
Reviewed-on: http://review.gluster.com/487
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Vijay Bellur

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