glusterfs.git/xlators/cluster/dht/src/dht-helper.c, branch v3.3.0qa26

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

cluster/dht: Handle get cached/hashed subvol failures gracefully

2012-02-19T12:46:26+00:00

Change-Id: I7a41c2876be04acd166b2004d9aa66af078d32ea
BUG: 790328
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.com/2757
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

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

2012-02-09T15:58:56+00:00

Change-Id: Id5078f270d0fec280b53d4aa7b16bbaf42a2df05
BUG: 784095
Signed-off-by: krishna 
Reviewed-on: http://review.gluster.com/2730
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

core: GFID filehandle based backend and anonymous FDs

2012-01-20T13:03:42+00:00

1. What
--------
This change introduces an infrastructure change in the filesystem
which lets filesystem operation address objects (inodes) just by its
GFID. Thus far GFID has been a unique identifier of a user-visible
inode. But in terms of addressability the only mechanism thus far has
been the backend filesystem path, which could be derived from the
GFID only if it was cached in the inode table along with the entire set
of dentry ancestry leading up to the root.

This change essentially decouples addressability from the namespace. It
is no more necessary to be aware of the parent directory to address a
file or directory.

2. Why
-------
The biggest use case for such a feature is NFS for generating
persistent filehandles. So far the technique for generating filehandles
in NFS has been to encode path components so that the appropriate
inode_t can be repopulated into the inode table by means of a recursive
lookup of each component top-down.

Another use case is the ability to perform more intelligent self-healing
and rebalancing of inodes with hardlinks and also to detect renames.

A derived feature from GFID filehandles is anonymous FDs. An anonymous FD
is an internal USABLE "fd_t" which does not map to a user opened file
descriptor or to an internal ->open()'d fd. The ability to address a file
by the GFID eliminates the need to have a persistent ->open()'d fd for the
purpose of avoiding the namespace. This improves NFS read/write performance
significantly eliminating open/close calls and also fixes some of today's
limitations (like keeping an FD open longer than necessary resulting
in disk space leakage)

3. How
-------

At each storage/posix translator level, every file is hardlinked inside
a hidden .glusterfs directory (under the top level export) with the name
as the ascii-encoded standard UUID format string. For reasons of performance
and scalability there is a two-tier classification of those hardlinks
under directories with the initial parts of the UUID string as the directory
names.

For directories (which cannot be hardlinked), the approach is to use a symlink
which dereferences the parent GFID path along with basename of the directory.
The parent GFID dereference will in turn be a dereference of the grandparent
with the parent's basename, and so on recursively up to the root export.

4. Development
---------------

4a. To leverage the ability to address an inode by its GFID, the technique is
to perform a "nameless lookup". This means, to populate a loc_t structure as:

loc_t {
   pargfid: NULL
   parent: NULL
   name: NULL
   path: NULL
   gfid: GFID to be looked up [out parameter]
   inode: inode_new () result [in parameter]
}

and performing such lookup will return in its callback an inode_t
populated with the right contexts and a struct iatt which can be
used to perform an inode_link () on the inode (without a parent and
basename). The inode will now be hashed and linked in the inode table
and findable via inode_find().

A fundamental change moving forward is that the primary fields in a
loc_t structure are now going to be (pargfid, name) and (gfid) depending
on the kind of FOP. So far path had been the primary field for operations.
The remaining fields only serve as hints/helpers.

4b. If read/write is to be performed on an inode_t, the approach so far
has been to: fd_create(), STACK_WIND(open, fd), fd_bind (in callback) and
then perform STACK_WIND(read, fd) etc. With anonymous fds now you can do
fd_anonymous (inode), STACK_WIND (read, fd). This results in great boost
in performance in the inbuilt NFS server.

5. Misc
-------
The inode_ctx_put[2] has been renamed to inode_ctx_set[2] to be consistent
with the rest of the codebase.

Change-Id: Ie4629edf6bd32a595f4d7f01e90c0a01f16fb12f
BUG: 781318
Reviewed-on: http://review.gluster.com/669
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

core: remove 'ino' variable from 'inode_t' structure

2011-11-16T11:44:32+00:00

Change-Id: I0f078d1753db65d2f2e0380d1b0450c114cf40dd
BUG: 3518
Reviewed-on: http://review.gluster.com/522
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

support for de-commissioning a node using 'remove-brick'

2011-09-13T09:10:12+00:00

to achieve this, we now create volume-file with
'decommissioned-nodes' option in distribute volume, then just
perform the rebalance set of operations (with 'force' flag set).

now onwards, the 'remove-brick' (with 'start' option) operation tries
to migrate data from removed bricks to existing bricks.

'remove-brick' also supports similar options as of replace-brick.

* (no options) -> works as 'force', will have the current behavior
         of remove-brick, ie., no data-migration, volume changes.

* start  (starts remove-brick with data-migration/draining process,
          which takes care of migrating data and once complete, will
          commit the changes to volume file)
* pause  (stop data migration, but keep the volume file intact with
          extra options whatever is set)
* abort  (stop data-migration, and fall back to old configuration)
* commit (if volume is stopped, commits the changes to volumefile)
* force  (stops the data-migration and commits the changes to
          volume file)

Change-Id: I3952bcfbe604a0952e68b6accace7014d5e401d3
BUG: 1952
Reviewed-on: http://review.gluster.com/118
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

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

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