glusterfs.git/xlators/nfs, branch v3.2.6qa2

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

2012-02-09T06:51:40+00:00

Change-Id: Id5078f270d0fec280b53d4aa7b16bbaf42a2df05
BUG: 784095
Signed-off-by: krishna 
Reviewed-on: http://review.gluster.com/2729
Reviewed-by: Anand Avati 
Tested-by: Gluster Build System

nfs: do not return -1 (error), if the transmission buffer list is empty

2011-11-04T12:37:17+00:00

In the rpc implementation of nfs suppose the transmission buffer list
is empty for the nfs server, -1 is being returned which is treated as
an error and the socket fd is closed to handle it. Because of this the
reply submission of the server will be failed. Thus if the transmission
buffer list is empty error should not be returned.

Change-Id: I42d0dada8fe0473daf4db085da10681d4926e1ae
BUG: 3765
Reviewed-on: http://review.gluster.com/671
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

check the return value of inode_path for less than or equal to zero

2011-10-28T11:14:56+00:00

Change-Id: I9bbdfe79664c1339b66819a6c7ea4b7698beb5c6
BUG: 3757
Reviewed-on: http://review.gluster.com/640
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

nfs: size_t is an unsigned type. Changing it to ssize_t for "writelen" variable. Also propogate error to the calling functions.

2011-10-10T11:03:16+00:00

Change-Id: If8ba73ac57bc235a28c1e1cdc7a5e11947e7a52f
BUG: 3526
Reviewed-on: http://review.gluster.com/400
Tested-by: Gluster Build System 
Reviewed-by: Shehjar Tikoo

gnfs/server: allow 255-char file names

2011-10-01T12:55:41+00:00

* Posix requires 255 character filenames(NAME_MAX), so
buffer to store a filename should be 256(+1 for
terminating '\0' character).

Change-Id: Id06ffa0e2d90a5950198cda3e4146ff10d25308b
BUG: 3572
Reviewed-on: http://review.gluster.com/500
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Krishna Srinivas

NFS : Posix compliance fixes.

2011-09-22T05:37:17+00:00

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

nfs-rpc: Use correct variable for volume-specific insecure ports check

2011-09-12T13:26:53+00:00

Change-Id: Ia53f64e923babdd3af2d82b13350c97fa25fac2d
BUG: 3515
Reviewed-on: http://review.gluster.com/355
Tested-by: Gluster Build System 
Reviewed-by: Shehjar Tikoo

mount/nfs: Gluster nfs crashes with subdirectory mount

2011-09-08T06:55:18+00:00

Glusterfs used to crash trying to dereference a NULL
pointer. Also, in mnt3_resolve_export_subdir, volume
name was prefixed to sub directory exported, resulting in
mount fail of sub directory. Fixed both issues.

Change-Id: I746f0c244b4cbf03033d73ac3e40518762d76385
BUG: 3481
Reviewed-on: http://review.gluster.com/346
Tested-by: Gluster Build System 
Reviewed-by: Shehjar Tikoo

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

2011-09-08T06:53:55+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: I78d8756252330201e165d788a29277b4bce0df90
BUG: 3510
Reviewed-on: http://review.gluster.com/358
Tested-by: Gluster Build System 
Reviewed-by: Shehjar Tikoo

xlators/nfs: Fix a typo in option description

2011-08-20T10:35:23+00:00

Change-Id: Ibb888357b87603544f360d181637138261fb3b71
BUG: 3445
Reviewed-on: http://review.gluster.com/275
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur