[LU-13426] "lfs migrate" on DoM component clobbers LOV EA FID Created: 08/Apr/20 Updated: 09/Jul/21 Resolved: 14/May/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.14.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Andreas Dilger | Assignee: | Mikhail Pershin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | DoM2, LTS12 | ||
| Issue Links: |
|
||||||||||||||||||||
| Severity: | 3 | ||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||
| Description |
|
Running the following test breaks the FID stored in the LOV EA. I was hoping that this FID would remain constant over the life of the file in order to implement LU-7607 "Preserve inode number after MDT migration", but it seems that migrating a file with a DOM component somehow breaks the layout in the LOV EA: tests# lfs setstripe -E 1M -L mdt -E 1G -c 3 -E eof /mnt/testfs/tt
tests# dd if=/dev/zero of=/mnt/testfs/tt bs=1M count=2
tests# lfs path2fid /mnt/testfs/tt
[0x200001b72:0x10c07:0x0]
tests# lfs getstripe -v /mnt/testfs/tt
components:
- lcme_id: 1
lcme_extent.e_start: 0
lcme_extent.e_end: 1048576
sub_layout:
lmm_seq: 0x200001b72
lmm_object_id: 0x10c07
lmm_fid: [0x200001b72:0x10c07:0x0]
lmm_stripe_count: 0
lmm_pattern: mdt
- lcme_id: 2
lcme_extent.e_start: 1048576
lcme_extent.e_end: 1073741824
sub_layout:
lmm_seq: 0x200001b72
lmm_object_id: 0x10c07
lmm_fid: [0x200001b72:0x10c07:0x0]
- lcme_id: 3
lcme_extent.e_start: 1073741824
lcme_extent.e_end: EOF
sub_layout:
lmm_seq: 0x200001b72
lmm_object_id: 0x10c07
lmm_fid: [0x200001b72:0x10c07:0x0]
tests# lfs migrate -c 3 /mnt/testfs/tt
tests# lfs getstripe -v /mnt/testfs/tt
lmm_seq: 0
lmm_object_id: 0x3000000000005
lmm_fid: [0x3000000000005:0x0:0x30000]
As you can see, the FID is originally [0x200001b72:0x10c07:0x0] and that is also stored in the LOV EA (irrelevant lines cut out) for each component as lmm_fid:, which is good. If there is no DOM component, then "lfs migrate -m" will not change the FID stored in the layout. However, as can be seen with a DOM component, the lmm_fid: is messed up. It looks like it wasn't initialized in the target layout, and/or not copied over during layout swap. |
| Comments |
| Comment by Mikhail Pershin [ 08/Apr/20 ] |
|
Andreas, I've just checked that and the same problem exists for any PFL->plain file migration
# lfs setstripe -E 1M -c1 -E eof -c2 /mnt/lustre/norm
# dd if=/dev/zero of=/mnt/lustre/norm bs=1M count=2
# lfs getstripe /mnt/lustre/norm -v
/mnt/lustre/norm
composite_header:
lcm_magic: 0x0BD60BD0
lcm_size: 264
lcm_flags: 0
lcm_layout_gen: 3
lcm_mirror_count: 1
lcm_entry_count: 2
components:
- lcme_id: 1
lcme_mirror_id: 0
lcme_flags: init
lcme_extent.e_start: 0
lcme_extent.e_end: 1048576
lcme_offset: 128
lcme_size: 56
sub_layout:
lmm_magic: 0x0BD10BD0
lmm_seq: 0x200000401
lmm_object_id: 0x4
lmm_fid: [0x200000401:0x4:0x0]
- lcme_id: 2
lcme_mirror_id: 0
lcme_flags: init
lcme_extent.e_start: 1048576
lcme_extent.e_end: EOF
lcme_offset: 184
lcme_size: 80
sub_layout:
lmm_magic: 0x0BD10BD0
lmm_seq: 0x200000401
lmm_object_id: 0x4
lmm_fid: [0x200000401:0x4:0x0]
# lfs migrate -c2 /mnt/lustre/norm
# lfs getstripe /mnt/lustre/norm -v
/mnt/lustre/norm
lmm_magic: 0x0BD10BD0
lmm_seq: 0
lmm_object_id: 0x2000000000003
lmm_fid: [0x2000000000003:0x0:0x20000]
It looks like generic problem while migrating to plain file from composite layout |
| Comment by Gerrit Updater [ 08/Apr/20 ] |
|
Mike Pershin (mpershin@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38172 |
| Comment by Gerrit Updater [ 14/May/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/38172/ |
| Comment by Peter Jones [ 14/May/20 ] |
|
Landed for 2.14 |
| Comment by Gerrit Updater [ 09/Jul/21 ] |
|
Etienne AUJAMES (eaujames@ddn.com) uploaded a new patch: https://review.whamcloud.com/44202 |