summaryrefslogtreecommitdiffstats
path: root/xlators/cluster/dht/src/Makefile.am
diff options
context:
space:
mode:
authorRaghavendra G <rgowdapp@redhat.com>2015-05-13 19:56:47 +0530
committerRaghavendra G <rgowdapp@redhat.com>2015-05-28 02:23:18 -0700
commit4df3ea9ab4d8a1aff98784460983b5f0cb4a9ee9 (patch)
tree90ee98a4f88ebfd43057c1e4b8457681931c897b /xlators/cluster/dht/src/Makefile.am
parent49b428433a03fcf709fdc8c08603b4cf02198e0a (diff)
cluster/dht: Don't rely on linkto xattr to find destination subvol during phase 2 of migration.
linkto xattr on source file cannot be relied to find where the data file currently resides. This can happen if there are multiple migrations before phase 2 detection by a client. For eg., * migration (M1, node1, node2) starts. * application writes some data. DHT correctly stores the state in inode context that phase-1 of migration is in progress * migration M1 completes * migration (M2, node2, node3) is triggered and completed * application resumes writes to the file. DHT identifies it as phase-2 of migration. However, linkto xattr on node1 points to node2, but the file is on node3. A lookup correctly identifies node3 as cached subvol TBD: When we identify phase-2 of a previous migration (say M1), there might be a migration in progress - say (M3, node3, node4). In this case we need to send writes to both (node3, node4) not just node3. Also, the inode state needs to correctly indicate that its in phase-1 of migration. I'll send this as a different patch. Change-Id: I1a861f766258170af2f6c0935468edb6be687b95 BUG: 1142423 Signed-off-by: Raghavendra G <rgowdapp@redhat.com> Reviewed-on: http://review.gluster.org/10805 Tested-by: NetBSD Build System
Diffstat (limited to 'xlators/cluster/dht/src/Makefile.am')
0 files changed, 0 insertions, 0 deletions