[Bugs] [Bug 1473140] New: Fix on demand file migration from client
bugzilla at redhat.com
bugzilla at redhat.com
Thu Jul 20 06:12:49 UTC 2017
https://bugzilla.redhat.com/show_bug.cgi?id=1473140
Bug ID: 1473140
Summary: Fix on demand file migration from client
Product: GlusterFS
Version: 3.10
Component: distribute
Assignee: spalai at redhat.com
Reporter: spalai at redhat.com
CC: bugs at gluster.org
Depends On: 1450975
+++ This bug was initially created as a clone of Bug #1450975 +++
Description of problem:
On demand file migration is broken in upstream currently. This bug is created
to track the fix for it.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--- Additional comment from Worker Ant on 2017-05-15 18:31:50 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#2) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-16 13:16:10 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#3) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-17 14:05:34 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#4) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-18 12:00:16 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#5) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-22 08:08:54 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#6) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-23 12:31:42 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#7) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-23 13:59:50 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#8) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-24 08:47:47 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#9) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-29 12:33:25 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#10) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-29 12:36:38 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#11) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-29 18:01:07 MVT ---
REVIEW: https://review.gluster.org/17115 (cluster/dht: fix on demand migration
files from client) posted (#12) for review on master by Susant Palai
(spalai at redhat.com)
--- Additional comment from Worker Ant on 2017-05-30 05:43:03 MVT ---
COMMIT: https://review.gluster.org/17115 committed in master by Shyamsundar
Ranganathan (srangana at redhat.com)
------
commit 1b1f871ca41b08671ebb327dba464aeb6c82e776
Author: Susant Palai <spalai at redhat.com>
Date: Tue Apr 25 18:32:45 2017 +0530
cluster/dht: fix on demand migration files from client
On demand migration of files i.e. migration done by clients
triggered by a setfattr was broken.
Dependency on defrag led to crash when migration was triggered from
client.
Note: This functionality is not available for tiered volumes. Migration
from tier served client will fail with ENOTSUP.
usage (But refer to the steps mentioned below to avoid any issues) :
setfattr -n "trusted.distribute.migrate-data" -v "1" <filename>
The purpose of fixing the on-demand client migration was to give a
workaround where the user has lots of empty directories compared to
files and want to do a remove-brick process.
Here are the steps to trigger file migration for remove-brick process
from
client. (This is highly recommended to follow below steps as is)
Let's say it is a replica volume and user want to remove a replica pair
named brick1 and brick2. (Make sure healing is completed before you run
these steps)
Step-1: Start remove-brick process
- gluster v remove-brick <volname> brick1 brick2 start
Step-2: Kill the rebalance daemon
- ps aux | grep glusterfs | grep rebalance\/ | awk '{print $2}' |
xargs kill
Step-3: Do a fresh mount as mentioned here
- glusterfs -s ${localhostname} --volfile-id rebalance/$volume-name
/tmp/mount/point
Step-4: Go to one of the bricks (among brick1 and brick2)
- cd <brick1 path>
Step-5: Run the following command.
- find . -not \( -path ./.glusterfs -prune \) -type f -not -perm 01000
-exec bash -c 'setfattr -n "distribute.fix.layout" -v "1"
${mountpoint}/$(dirname '{}')' \; -exec setfattr -n
"trusted.distribute.migrate-data" -v "1" ${mountpoint}/'{}' \;
This command will ignore the linkto files and empty directories. Do a
fix-layout of
the parent directory. And trigger a migration operation on the files.
Step-6: Once this process is completed do "remove-brick force"
- gluster v remove-brick <volname> brick1 brick2 force
Note: Use the above script only when there are large number of empty
directories.
Since the script does a crawl on the brick side directly and avoids
directories those
are empty, the time spent on fixing layout on those directories are
eliminated(even if the script
does not do fix-layout on empty directories, post remove-brick a fresh
layout will be built
for the directory, hence not affecting application continuity).
Detailing the expectation for hardlink migartion with this patch:
Hardlink is migrated only for remove-brick process. It is highly
essential
to have a new mount(step-3) for the hardlink migration to happen. Why?:
setfattr operation is an inode based operation. Since, we are doing
setfattr from
fuse mount here, inode_path will try to build path from the linked
dentries to the inode.
For a file without hardlinks the path construction will be correct. But
for hardlinks,
the inode will have multiple dentries linked.
Without fresh mount, inode_path will always get the most
recently linked dentry.
e.g. if there are three hardlinks named dir1/link1, dir2/link2,
dir3/link3, on a client
where these hardlinks are looked up, inode_path will always return the
path dir3/link3
if dir3/link3 was looked up most recently. Hence, we won't be able to
create linkto
files for all other hardlinks on destination (read
gf_defrag_handle_hardlink for more details
on hardlink migration).
With a fresh mount, the lookup and setfattr become serialized.
e.g. link2 won't be
looked up until link1 is looked up and migrated. Hence, inode_path will
always have the correct
path, in this case link1 dentry is picked up(as this is the most
recently looked up inode) and
the path is built right.
Note: If you run the above script on an existing mount(all entries
looked up), hard links may
not be migrated, but there should not be any other issue. Please raise
a bug, if you find any
issue.
Tests: Manual
Change-Id: I9854cdd4955d9e24494f348fb29ba856ea7ac50a
BUG: 1450975
Signed-off-by: Susant Palai <spalai at redhat.com>
Reviewed-on: https://review.gluster.org/17115
NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
Smoke: Gluster Build System <jenkins at build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp at redhat.com>
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1450975
[Bug 1450975] Fix on demand file migration from client
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Ihe4zHmHFA&a=cc_unsubscribe
More information about the Bugs
mailing list