Details
-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
3
-
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.
