glusterfs.git/xlators/cluster/dht/src/switch.c, branch v3.3.0qa39

core: adding extra data for fops

2012-03-22T23:40:27+00:00

with this change, the xlator APIs will have a dictionary as extra
argument, which is passed between all the layers. This can be
utilized for overloading in some of the operations.

Change-Id: I58a8186b3ef647650280e63f3e5e9b9de7827b40
Signed-off-by: Amar Tumballi 
BUG: 782265
Reviewed-on: http://review.gluster.com/2960
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

mempool: adjustments in pool sizes

2012-02-22T12:23:48+00:00

* while creating 'rpc_clnt', the caller knows what would be the ideal
  load on it, so an extra argument to set some pool sizes

* while creating 'rpcsvc', the caller knows what would be the ideal
  load of it, so an extra argument to set request pool size

* cli memory footprint is reduced

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

core: utilize mempool for frame->local allocations

2012-02-21T10:42:09+00:00

in each translator, which uses 'frame->local', we are using
GF_CALLOC/GF_FREE, which would be costly considering the
number of allocation happening in a lifetime of 'fop'. It
would be good to utilize the mem pool framework for xlator's
local structures, so there is no allocation overhead.

Change-Id: Ida6e65039a24d9c219b380aa1c3559f36046dc94
Signed-off-by: Amar Tumballi 
BUG: 765336
Reviewed-on: http://review.gluster.com/2772
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

distribute rebalance: handle the open file migration

2011-09-13T06:57:38+00:00

Complexity involved: To migrate a file with open fd, we have to
notify the other client process which has the open fd, and make
sure the write()s happening on that fd is properly synced to the
migrated file. Once the migration is complete, the client
process which has open-fd should get notified and it should
start performing all the operations on the new subvolume,
instead of earlier cached volume.

How to solve the notification part:

We can overload the 'postbuf' attribute in the _cbk() function to
understand if a file is 'under-migration' or 'migration-complete'
state. (This will be something similar to deciding whether a file
is DHT-linkfile by its 'mode').

Overall change includes below mentioned major changes:

1. dht_linkfile is decided by only 2 factors (mode(01000),
   xattr(trusted.glusterfs.dht.linkto)), instead of earlier
   3 factors (size==0)

2. in linkfile self-heal part (in 'dht_lookup_everywhere_cbk()'),
   don't delete a linkfile if there is a open-fd on it. It means,
   there may be a migration in progress.

3. if a file's revalidate fails with ENOENT, it may be due to file
   migration, and hence need a lookup_everywhere()

4. There will be 2 phases of file-migration.

-> Phase 1: Migration in progress
   * The source data file will have SGID and STICKY bit set in its mode.
   * The source data file will have a 'linkto' xattr pointing the
     destination.
   * Destination file will have mode set to '01000', and 'linkto' xattr
     set to itself.

-> Phase 2: File migration Complete
   * The source data file will have mode '01000', and will be 'truncated'
     to size 0.
   * The destination file will have inherited mode from the source. (without
     sgid and sticky bit) and its 'linkto' attribute will be removed.

4. Changes in distribute to work smoothly with a file which is in migration /
   got migrated.

The 'fops' are divided into 3 categories, inode-read, inode-write and others.
inode-read fops need to handle only 'phase 2' notification, where as, the
inode-write fops need to handle both 'phase 1' and phase2. The inode-write
operations will be done on source file, and if any of 'file-migration' procedures
are detected in _cbk(), then the operations should be performed on the destination
too.

when a phase-2 is detected, then the inode-ctx itself should be changed to represent
a new layout.

With these changes, the open file migration will work smoothly with multiple clients.

Change-Id: I512408463814e650f34c62ed009bf2101d016fd6
BUG: 3071
Reviewed-on: http://review.gluster.com/209
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

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

LICENSE: s/GNU Affero General Public/GNU General Public/

2011-08-06T13:33:52+00:00

Change-Id: I3914467611e573cccee0d22df93920cf1b2eb79f
BUG: 3348
Reviewed-on: http://review.gluster.com/182
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

distribute: bring in feature to do rebalance from inside

2011-07-14T08:01:44+00:00

do the 'rebalance' on a file with 'setxattr()' with
'distribute.migrate-data' key. the valid 'value' is "force" or
anything else.

current implementation of 'rebalance' is same as 'glusterd-rebalance',
and hence comes with limitation of not rebalancing hardlinks, non-regular
files, and files with open-fds.

Signed-off-by: Amar Tumballi 
Signed-off-by: Anand Avati 

BUG: 3070 (After 'rebalance', the gfid of the file gets changed)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=3070

core: fill 'ia_ino' from 'ia_gfid' in 'storage/posix' to preserve same ino number

2011-06-17T06:24:56+00:00

take the least significant 64bit from gfid and assign it to 'ia_ino',
hence for a given file (or directory), the 'ia_ino' number is always
same, and we need not worry about the 'itransform' in 'cluster/*'
translators.

Signed-off-by: Amar Tumballi 
Signed-off-by: Anand Avati 

BUG: 3042 (inode number should be constant on storage)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=3042

cluster/distribute: remove the unused variable from 'conf'

2011-06-16T16:15:46+00:00

Signed-off-by: Amar Tumballi 
Signed-off-by: Anand Avati 

BUG: 3013 (error in the log file upon taking the statedump)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=3013

removed reference to GF_LOG_NORMAL

2011-04-07T18:40:25+00:00

instead used GF_LOG_INFO, which is more standard log level.

Signed-off-by: Amar Tumballi 
Signed-off-by: Vijay Bellur 

BUG: 2669 (RuntimeError: cannot recognize log level "normal")
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=2669