{"shas":[["a07bb18c8adeb8597f62095c5d1361c5bad01f09","54cf1edf1143872699c8b24cfc4bf05ead9e0365@gluster.com","distribute rebalance: handle the open file migration\n\nComplexity involved: To migrate a file with open fd, we have to\nnotify the other client process which has the open fd, and make\nsure the write()s happening on that fd is properly synced to the\nmigrated file. Once the migration is complete, the client\nprocess which has open-fd should get notified and it should\nstart performing all the operations on the new subvolume,\ninstead of earlier cached volume.\n\nHow to solve the notification part:\n\nWe can overload the 'postbuf' attribute in the _cbk() function to\nunderstand if a file is 'under-migration' or 'migration-complete'\nstate. (This will be something similar to deciding whether a file\nis DHT-linkfile by its 'mode').\n\nOverall change includes below mentioned major changes:\n\n1. dht_linkfile is decided by only 2 factors (mode(01000),\n   xattr(trusted.glusterfs.dht.linkto)), instead of earlier\n   3 factors (size==0)\n\n2. in linkfile self-heal part (in 'dht_lookup_everywhere_cbk()'),\n   don't delete a linkfile if there is a open-fd on it. It means,\n   there may be a migration in progress.\n\n3. if a file's revalidate fails with ENOENT, it may be due to file\n   migration, and hence need a lookup_everywhere()\n\n4. There will be 2 phases of file-migration.\n\n-> Phase 1: Migration in progress\n   * The source data file will have SGID and STICKY bit set in its mode.\n   * The source data file will have a 'linkto' xattr pointing the\n     destination.\n   * Destination file will have mode set to '01000', and 'linkto' xattr\n     set to itself.\n\n-> Phase 2: File migration Complete\n   * The source data file will have mode '01000', and will be 'truncated'\n     to size 0.\n   * The destination file will have inherited mode from the source. (without\n     sgid and sticky bit) and its 'linkto' attribute will be removed.\n\n4. Changes in distribute to work smoothly with a file which is in migration /\n   got migrated.\n\nThe 'fops' are divided into 3 categories, inode-read, inode-write and others.\ninode-read fops need to handle only 'phase 2' notification, where as, the\ninode-write fops need to handle both 'phase 1' and phase2. The inode-write\noperations will be done on source file, and if any of 'file-migration' procedures\nare detected in _cbk(), then the operations should be performed on the destination\ntoo.\n\nwhen a phase-2 is detected, then the inode-ctx itself should be changed to represent\na new layout.\n\nWith these changes, the open file migration will work smoothly with multiple clients.\n\nChange-Id: I512408463814e650f34c62ed009bf2101d016fd6\nBUG: 3071\nReviewed-on: http://review.gluster.com/209\nTested-by: Gluster Build System <jenkins@build.gluster.com>\nReviewed-by: Vijay Bellur <vijay@gluster.com>","Amar Tumballi"]],"ref":"refs/heads/master","size":1,"head":"a07bb18c8adeb8597f62095c5d1361c5bad01f09","push_id":42510345}