[LU-13425] "run 'lfs migrate -m 1 -c 1 -H 3 dir1' to finish migration" is broken Created: 07/Apr/20 Updated: 05/Apr/22 Resolved: 19/Apr/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.14.0, Lustre 2.12.5 |
| Fix Version/s: | Lustre 2.14.0 |
| Type: | Bug | Priority: | Major |
| Reporter: | Andreas Dilger | Assignee: | Emoly Liu |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | dne3 | ||
| Issue Links: |
|
||||||||||||
| Severity: | 3 | ||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||
| Description |
|
While testing tests# lfs migrate -m 1 /mnt/testfs/dir1
lfs migrate: /mnt/testfs/dir1/hosts migrate failed: Operation not supported (95)
tests# lfs migrate -m 0 /mnt/testfs/dir1
LustreError: 30963:0:(mdd_dir.c:4209:mdd_migrate()) testfs-MDD0000: 'dir1' migration was interrupted, run 'lfs migrate -m 1 -c 1 -H 3 dir1' to finish migration.
tests# lfs migrate -m1 -c 1 -H 3 /mnt/testfs/dir1
lfs migrate migrate: bad stripe hash type '3'
tests# lfs getdirstripe /mnt/testfs/dir1
lmv_stripe_count: 2 lmv_stripe_offset: 1 lmv_hash_type: crush,migrating
mdtidx FID[seq:oid:ver]
1 [0x240001b71:0xf:0x0]
0 [0x200001b72:0xe480:0x0]
so it printed the "run 'lfs migrate ...'" error to the console, but in fact that command doesn't work because the numeric hash value "-H 3" is not accepted by "lfs migrate". The simplest fix is to allow specifying the numeric hash type like "lfs migrate ... -H 3" in order to resume directory migration, as stated in the error message. I don't think that "lfs" or the client should even try to validate this hash type before passing it to the MDS, since the client may be old, and the directory is using a new hash that it doesn't know about. The MDS should reject invalid hash types from the client anyway (e.g. malicious user, or new client and old server). The MDS really shouldn't even need the hash type or other arguments to be passed, since it already knows this information itself (since it generated the message in the first place). It would be better (if possible) to just print "run 'lfs migrate <full_path>' to finish migration" (maybe using fid2path to generate the pathname?). Best would be to restart the migration automatically if this is hit (at least once, but not repeatedly if it is broken for some reason like |
| Comments |
| Comment by Lai Siyao [ 08/Apr/20 ] |
|
Because directory migration is done recursively, which means the same arguments will be used to migrate sub-directories, while only MDS can know whether argument is correct, and can adjust it, it can't notify client to use the correct arguments to migrate sub-directories. |
| Comment by Andreas Dilger [ 08/Apr/20 ] |
|
I'm thinking the client shouldn't even need to specify what the arguments are, since the MDS already knows the correct values for each directory. The client can specify any values at all (or none) and they would be ignored for directories that have partial migration. It isn't clear whether we need to resume recursive migration, just finish off the partially-migrated directory. |
| Comment by Gerrit Updater [ 08/Apr/20 ] |
|
Emoly Liu (emoly@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38182 |
| Comment by Gerrit Updater [ 19/Apr/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/38182/ |
| Comment by Peter Jones [ 19/Apr/20 ] |
|
Landed for 2.14 |