Self-heald: Print the time stamp of the event-history

Change-Id: I45767e26288ef6de6446ddf2ea82ed31e128d227
BUG: 796579
Signed-off-by: Pranith Kumar K <pranithk@gluster.com>
Reviewed-on: http://review.gluster.com/3277
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
nfs/nlm: procedures for PC clients

*  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 <rajesh@redhat.com>
Reviewed-on: http://review.gluster.com/3212
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krishna Srinivas <krishna@gluster.com>
libglusterfs/fd: while dumping the fd_ctx use fd->xl_count

While dumping the fd_ctx when statedump is issued fd->xl_count should be
used to determine the number of xlators instead of using latest graph's count,
since while creating the fd only those many slots would have been allocated
as the number of xlators in the graph at that instant. Then the graph would have
changed, thus the xl count.

All the above things should happen before any operation is done on fd, otherwise
fd_ctx_set will allocate the extra slots for the new xlators present in the
graph.

Also added the program which can be used to reproduce the bug.

Change-Id: I11fe75d71ef5d37e29e2958d53752aa31098c313
BUG: 820887
Signed-off-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
Reviewed-on: http://review.gluster.com/3335
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
protocol/client: check if the name is NULL before duping it

Change-Id: I1cefc34af6fae2e71b05179824963e06361c35a2
BUG: 822385
Signed-off-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
Reviewed-on: http://review.gluster.com/3353
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
Tested-by: Anand Avati <avati@redhat.com>
Fixed a memory leak in stripe translator.

When iobuf is created it has reference count = 1.
After iobref_add (local->iobref, iobuf); reference count becomes 2.
After iobref_unref(local->iobref); it becomes 1 and never becomes 0.
So iobuf never deletes and this causes a memory leak.

I emulated it, creating files on brick manually.
After 5 mins of:
while true; do dd if=file of=/dev/zero bs=16384; done
top showed me this:
4618 root      20   0 1721m 1.5g 1868 S  0.0 16.2   5:41.77 glusterfs

1.5 gb of memory has leaked.

For what this if for? Can it be true in the normal conditions?
if ((local->replies[i].op_ret < local->replies[i].requested_size) &&
    (local->stbuf_size > (local->offset + op_ret))) {
May be delete it entirely?

Change-Id: I17c115ab566e5bba662dd809e0c747db3c0310c8
BUG: 822378
Signed-off-by: Alexander Bersenev <bay@hackerdom.ru>
Reviewed-on: http://review.gluster.com/3340
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Anand Avati <avati@redhat.com>