glusterfs-nsr.git/xlators/mount/fuse/src, branch master

fuse: minor improvements for readdir(plus)

2014-04-27T17:51:11+00:00

Instead of using 'int' for the sizes, use a 'size_t' as it is more
correct. Save the size of a fuse_dirent in a temporary variable so that
strlen() on the filename is called fewer times.

Also correcting some typos in comments.

Change-Id: Ic62d9d729a86a1a6a53ed1354fce153bac01d860
BUG: 1074023
Reported-by: Kaleb S. KEITHLEY 
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/7547
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

osx: Compilation fixes

2014-04-25T19:02:30+00:00

Change-Id: I822936cbeb4ec8af46be8e94644ea666b919ae5c
BUG: 1089172
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/7556
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

build: MacOSX Porting fixes

2014-04-24T21:41:48+00:00

git@forge.gluster.org:~schafdog/glusterfs-core/osx-glusterfs

Working functionality on MacOSX

 - GlusterD (management daemon)
 - GlusterCLI (management cli)
 - GlusterFS FUSE (using OSXFUSE)
 - GlusterNFS (without NLM - issues with rpc.statd)

Change-Id: I20193d3f8904388e47344e523b3787dbeab044ac
BUG: 1089172
Signed-off-by: Harshavardhana 
Signed-off-by: Dennis Schafroth 
Tested-by: Harshavardhana 
Tested-by: Dennis Schafroth 
Reviewed-on: http://review.gluster.org/7503
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

fuse: prevent READDIR(P) from writing to much data to /dev/fuse

2014-04-21T17:25:21+00:00

In an environment with mixed architectures (32-bit servers, 64-bit
client), it is possible that the on-wire Reply on a READDIR(P) procedure
contains more direntries than the client can fit in the maximum size
that the fuse-request indicated.

A direntry is a dynamically sized structure, because the structure
contains the name of the entry. The client sends a maximum size in the
READDIR(P) Call to the server, and the server uses this size to limit
the number of direntries to return. In case the server can pack more
direntries in the requested maximum size (due to alignment differences
between the architectures), it can happen that the client unpacks the
list of direntries into a buffer that exceeds the maximum size that was
given in the initial fuse-request.

This change introduces a check for the maximum requested size of the
fuse-response in fuse_readdir_cbk() and fuse_readdirp_cbk(). When the
conversion from gluster-direntries to the fuse-direntry format takes
place, the maximum size is checked, and the 'extra' direntries are
discarded. The next readdir()/getdents() that is done, will fetch the
just discarded direntries again.

In addition to this bugfix, some extra logging in send_fuse_iov() and
send_fuse_data() has been added to help diagnosing similar issues.

Change-Id: If2eecfcdf9c248f3820035601446d2c89ff9d1a1
BUG: 1074023
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/7278
Tested-by: Gluster Build System 
Reviewed-by: Xavier Hernandez 
Reviewed-by: Anand Avati

fuse: allow xlators to request for direct-io-mode on virtual files

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

Translators like meta, create virtual files with dynamic content
generated only at the time of open(). Therefore the file size
returned in lookup or stat is 0 (just like files in /proc). However
the VFS does not read beyond the size, and if the size is 0, no
READ ever reaches gluster for that file -- unless direct-io-mode
is enabled.

This patch allows translators to return "direct-io-mode" flag for
such 0-byte virtual files in xdata of open_cbk/create_cbk.

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

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

protocol/server: do not do root-squashing for trusted clients

2014-02-11T07:32:05+00:00

* As of now clients mounting within the storage pool using that machine's
  ip/hostname are trusted clients (i.e clients local to the glusterd).

* Be careful when the request itself comes in as nfsnobody (ex: posix tests).
  So move the squashing part to protocol/server when it creates a new frame
  for the request, instead of auth part of rpc layer.

* For nfs servers do root-squashing without checking if it is trusted client,
  as all the nfs servers would be running within the storage pool, hence will
  be trusted clients for the bricks.

* Provide one more option for mounting which actually says root-squash
  should/should not happen. This value is given priority only for the trusted
  clients. For non trusted clients, the volume option takes the priority. But
  for trusted clients if root-squash should not happen, then they have to be
  mounted with root-squash=no option. (This is done because by default
  blocking root-squashing for the trusted clients will cause problems for smb
  and UFO clients for which the requests have to be squashed if the option is
  enabled).

* For geo-replication and defrag clients do not do root-squashing.

* Introduce a new option in open-behind for doing read after successful open.

Change-Id: I8a8359840313dffc34824f3ea80a9c48375067f0
BUG: 954057
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/4863
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

mount/fuse: adding a setxattr filter pass for geo-rep create.

2014-01-28T10:07:27+00:00

Adding filter pass for setxattr when key is "glusterfs.gfid.newfile".
This was blocking creates at slave volume.

Change-Id: I61455abd8688c52ac6894b5a04ba050076117ea3
BUG: 1054199
Signed-off-by: Ajeet Jha 
Reviewed-on: http://review.gluster.org/6797
Reviewed-by: Venky Shankar 
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

syncop: Change return value of syncop

2014-01-20T07:05:15+00:00

Problem:
We found a day-1 bug when syncop_xxx() infra is used inside a synctask with
compilation optimization (CFLAGS -O2).

Detailed explanation of the Root cause:
We found the bug in 'gf_defrag_migrate_data' in rebalance operation:

Lets look at interesting parts of the function:

int
gf_defrag_migrate_data (xlator_t *this, gf_defrag_info_t *defrag, loc_t *loc,
                        dict_t *migrate_data)
{
.....
code section - [ Loop ]
        while ((ret = syncop_readdirp (this, fd, 131072, offset, NULL,
                                       &entries)) != 0) {
.....
code section - [ ERRNO-1 ] (errno of readdirp is stored in readdir_operrno by a
thread)
                /* Need to keep track of ENOENT errno, that means, there is no
                   need to send more readdirp() */
                readdir_operrno = errno;
.....
code section - [ SYNCOP-1 ] (syncop_getxattr is called by a thread)
                        ret = syncop_getxattr (this, &entry_loc, &dict,
                                               GF_XATTR_LINKINFO_KEY);
code section - [ ERRNO-2]   (checking for failures of syncop_getxattr(). This
may not always be executed in same thread which executed [SYNCOP-1])
                        if (ret < 0) {
                                if (errno != ENODATA) {
                                        loglevel = GF_LOG_ERROR;
                                        defrag->total_failures += 1;
.....
}

the function above could be executed by thread(t1) till [SYNCOP-1] and code
from [ERRNO-2] can be executed by a different thread(t2) because of the way
syncop-infra schedules the tasks.

when the code is compiled with -O2 optimization this is the assembly code that
is generated:
 [ERRNO-1]
1165                        readdir_operrno = errno; <<---- errno gets expanded
as *(__errno_location())
   0x00007fd149d48b60 <+496>:        callq  0x7fd149d410c0 
   0x00007fd149d48b72 <+514>:        mov    %rax,0x50(%rsp) <<------ Address
returned by __errno_location() is stored in a special location in stack for
later use.
   0x00007fd149d48b77 <+519>:        mov    (%rax),%eax
   0x00007fd149d48b79 <+521>:        mov    %eax,0x78(%rsp)
....
 [ERRNO-2]
1281                                        if (errno != ENODATA) {
   0x00007fd149d492ae <+2366>:        mov    0x50(%rsp),%rax <<-----  Because
it already stored the address returned by __errno_location(), it just
dereferences the address to get the errno value. BUT THIS CODE NEED NOT BE
EXECUTED BY SAME THREAD!!!
   0x00007fd149d492b3 <+2371>:        mov    $0x9,%ebp
   0x00007fd149d492b8 <+2376>:        mov    (%rax),%edi
   0x00007fd149d492ba <+2378>:        cmp    $0x3d,%edi

The problem is that __errno_location() value of t1 and t2 are different. So
[ERRNO-2] ends up reading errno of t1 instead of errno of t2 even though t2 is
executing [ERRNO-2] code section.

When code is compiled without any optimization for [ERRNO-2]:
1281                                        if (errno != ENODATA) {
   0x00007fd58e7a326f <+2237>:        callq  0x7fd58e797300
<<--- As it is calling __errno_location() again it gets the
location from t2 so it works as intended.
   0x00007fd58e7a3274 <+2242>:        mov    (%rax),%eax
   0x00007fd58e7a3276 <+2244>:        cmp    $0x3d,%eax
   0x00007fd58e7a3279 <+2247>:        je     0x7fd58e7a32a1


Fix:
Make syncop_xxx() return (-errno) value as the return value in
case of errors and all the functions which make syncop_xxx() will need to use
(-ret) to figure out the reason for failure in case of syncop_xxx() failures.

Change-Id: I314d20dabe55d3e62ff66f3b4adb1cac2eaebb57
BUG: 1040356
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/6475
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati