glusterfs.git/xlators/protocol/client/src/client.h, branch v3.5.3beta2

protocol/client: conn-id should be unique when lk-heal is off

2014-06-27T08:42:03+00:00

        Backport of http://review.gluster.org/6669

Problem:
It was observed that in some cases client disconnects
and re-connects before server xlator could detect that a
disconnect happened. So it still uses previous fdtable and ltable.
But it can so happen that in between disconnect and re-connect
an 'unlock' fop may fail because the fds are marked 'bad' in client
xlator upon disconnect. Due to this stale locks remain on the brick
which lead to hangs/self-heals not happening etc.

For the exact bug RCA please look at
https://bugzilla.redhat.com/show_bug.cgi?id=1049932#c0

Fix:
When lk-heal is not enabled make sure connection-id is different for
every setvolume. This will make sure that a previous connection's
resources are not re-used in server xlator.

BUG: 1113894
Change-Id: I5090f832730e4072c4b6b6758e64f757b911bd49
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8187
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

rpc: implement server.manage-gids for group resolving on the bricks

2014-05-23T08:34:02+00:00

The new volume option 'server.manage-gids' can be enabled in
environments where a user belongs to more than the current absolute
maximum of 93 groups. This option triggers the following behavior:

1. The AUTH_GLUSTERFS structure sent by GlusterFS clients (fuse, nfs or
   libgfapi) will contain only one (1) auxiliary group, instead of
   a full list. This reduces network usage and prevents problems in
   encoding the AUTH_GLUSTERFS structure which should fit in 400 bytes.
2. The single group in the RPC Calls received by the server is replaced
   by resolving the groups server-side. Permission checks and similar in
   lower xlators are applied against the full list of groups where the
   user belongs to, and not the single auxiliary group that the client
   sent.

Cherry picked from commit 2fd499d148fc8865c77de8b2c73fe0b7e1737882:
> BUG: 1053579
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/7501
> Tested-by: Gluster Build System 
> Reviewed-by: Santosh Pradhan 
> Reviewed-by: Harshavardhana 
> Reviewed-by: Anand Avati 

Change-Id: I9e540de13e3022f8b63ff893ecba511129a47b91
BUG: 1096425
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/7830
Tested-by: Gluster Build System 
Reviewed-by: Santosh Pradhan

libglusterfs: Add monotonic clocking counter for timer thread

2013-10-15T07:14:57+00:00

gettimeofday() returns the current wall clock time and timezone.
Using these functions in order to measure the passage of time
(how long an operation took) therefore seems like a no-brainer.

This time suffer's from some limitations:

a. They have a low resolution: “High-performance” timing by
definition, requires clock resolutions into the microseconds
or better.

b. They can jump forwards and backwards in time: Computer
clocks all tick at slightly different rates, which causes
the time to drift. Most systems have NTP enabled which
periodically adjusts the system clock to keep them in sync
with “actual” time. The adjustment can cause the clock to
suddenly jump forward (artificially inflating your timing
numbers) or jump backwards (causing your timing calculations
to go negative or hugely positive). In such cases timer
thread could go into an infinite loop.

From 'man gettimeofday':
----------
..
..
The time returned by gettimeofday() is affected by discontinuous
jumps in the system time (e.g., if the system administrator manually
changes the system time).  If you need a monotonically increasing
clock, see clock_gettime(2).
..
..
----------

Rationale:

For calculating interval timing for Timer thread, all that’s
needed should be clock as a simple counter that increments
at a stable rate.

This is necessary to avoid the jumps which are caused by using
"wall time", this counter must be monotonic that can never
“tick” backwards, ever.

Change-Id: I701d31e71a85a73d21a6c5cd15583e7a5a645eeb
BUG: 1017993
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/6070
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

protocol/client: Prevent excessive logging of client's "disconnect" messages.

2013-05-28T11:38:25+00:00

Problem: Currently when gluster volume start force is executed, client process
         will talk to glusterd to get the port of the brick. But if brick's path
         is not available it cannot return brick's port. So client process will
         keep connecting and disconnecting from glusterd for port-query which
         is ultimately responsible for execssive logging of disconnect messages.

Fix:     Message will be logged just once at INFO level after the first
         disconnect from glusterd. Afterwards "disconnect" messages will be
         logged in DEBUG mode.

Change-Id: I2b787f3820b5da45e090c562e5698fcfe24a02cd
BUG: 959969
Signed-off-by: Venkatesh Somyajulu 
Reviewed-on: http://review.gluster.org/4953
Reviewed-by: Amar Tumballi 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

protocol/client: Periodically attempt reopens

2013-02-03T19:33:31+00:00

If the brick is taken down and the hard disk is replaced
and the brick is brought back up, the re-opens of the open-fds
will fail because the file is not present on the brick.
Re-opens are not attempted even if the files are re-created by
self-heal until the brick is brought down after the files are
re-created and brought back up. This is a problem with a VM-store
in a replica-setup.  Until the fd is re-opened the writes will
never happen on the brick where the hard-disk is replaced.
To handle this situation gracefully, client xlator is enhanced
to perform finodelk, fxattrop, writev, readv using anonymous fds
if the file is yet to be re-opened. If the fop succeeds then client
xlator attempts re-open.

Change-Id: I1cc6d1bbf8227cd996868ab2ed0a57fb05e00017
BUG: 821056
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4358
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy

protocol/client: Add fdctx back to saved-list after reopen

2013-02-03T19:33:18+00:00

Change-Id: I01caa1b51570359e6e3ffe1ffb7279cbdb0b0c64
BUG: 821056
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4357
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy

protocol/client: add an option to filter O_DIRECT flag in open

2012-11-28T11:37:03+00:00

with the option, the idea is all client-side caching will be disabled,
where as on server side process, the fd will be treated as a regular
fd, thus helping the performance better.

"gluster volume set  remote-dio enable" would set
this option in client protocol volumes.

Change-Id: Id2255a167137f8fee20849513e3011274dc829b4
Signed-off-by: Amar Tumballi 
BUG: 845213
Reviewed-on: http://review.gluster.org/4206
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

protocol/client: quick-reconnect after portmap query

2012-09-26T04:14:42+00:00

Currently the disconnect after a portmap query is treated like an
ordinary disconnect and the reconnection attempt (in this case, to
the brick) is attempted only after 3 secs. This results in a delay
which is unnecessary.

Mark the disconnection happening because of a successful portmap
query as needing a 'quick reconnect' to avoid the delay for this
special case.

Change-Id: I43c8292ff0c30858d883ff3569a3761acbf2f5eb
BUG: 860220
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/3994
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

protocol/client: Re-open should not have O_CREAT|O_TRUNC|O_EXCL

2012-06-20T06:50:30+00:00

RCA
The bug is observed in 3.2.x because posix xlator changes
the uid/gid of file as per frame->root-uid/gid if O_CREAT flag
is set in open fop. Posix does not do this in 3.3.x so that
bug does not appear anymore but this issue exposed the actual
bug in client xlator re-open. Re-open of a file on re-connection
should not perform re-open with the same flags at the time of
open/create/opendir. Imagine a case where a file is opened with
O_TRUNC|O_RDWR and some data is written to it, now if the brick
goes down and comes back the file will be truncated.
When I tested this case, the file is not truncated because locks
xlator resets O_TRUNC unconditionally.
Client xlator re-open bug and locks xlator bug cancel each other.

Fix
Reset O_CREAT|O_TRUNC|O_EXCL flags in re-open.
Locks xlator should not reset O_TRUNC.

Additional changes
Removed wbflags as it is not assigned at all.

Testcases
Automated go program is at:
://bugzilla.redhat.com/show_bug.cgi?id=807976#c2

Change-Id: I0080344fdda2e62e7c976c35a5bf5f1fa8838891
BUG: 807976
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.com/3582
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Raghavendra Bhat 
Reviewed-by: Anand Avati

protocol/client: Remember the gfid of opened fd

2012-06-06T19:35:44+00:00

This is needed when the fresh lookup triggers self-heal, gfid
won't be present in inode yet. Similar situation happens with
Rebalance as it does not perform inode_link.
Added similar fix for re-opendir.
Removed inode from fdctx and removed some duplication of code.

Change-Id: Ic94e5738c8585ed86801d2eed9ddab1015246710
BUG: 826080
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.com/3517
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Anand Avati