[LU-15727] lod_get_default_lov_striping() misinterprets composite striping for append Created: 07/Apr/22 Updated: 16/Jan/24 Resolved: 12/Jul/22 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.16.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | John Hammond | Assignee: | John Hammond |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Severity: | 3 | ||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||
| Description |
|
In lod_get_default_lov_striping() if the default striping is composite and dah_append_stripes is non zero then we try to read lmm_pattern from a struct lov_comp_md_v1 which isn't really there and we get confused. To reproduce: $LUSTRE/tets/llmount.sh POOL=lustre.pool0 lctl pool_new $POOL lctl pool_add $POOL OST0000 lctl pool_add $POOL OST0001 lfs setstripe -E 1M -c 1 -p $POOL -E 2M -c 2 -p $POOL -E eof -c -1 /mnt/lustre lctl set_param debug='+layout trace' lctl clear echo XXX >> /mnt/lustre/f0 lctl dk | grep lod_get_default_lov_striping Output: 00000004:00000001:1.0:1649345555.830519:0:1905344:0:(lod_object.c:5263:lod_get_default_lov_striping()) Process entered 00000004:00000001:1.0:1649345555.830540:0:1905344:0:(lod_object.c:5347:lod_get_default_lov_striping()) Process leaving (rc=18446744073709551594 : -22 : ffffffffffffffea) 00000004:00000001:1.0:1649345555.830543:0:1905344:0:(lod_object.c:5263:lod_get_default_lov_striping()) Process entered 00000004:00000001:1.0:1649345555.830553:0:1905344:0:(lod_object.c:5347:lod_get_default_lov_striping()) Process leaving rc=18446744073709551594 : -22 : ffffffffffffffea)
if (!lov_pattern_supported(v1->lmm_pattern) &&
!(v1->lmm_pattern & LOV_PATTERN_F_RELEASED)) {
lod_free_def_comp_entries(lds);
RETURN(-EINVAL);
}
This is because we use composite in two different senses: lti_ea_store contains a composite layout, and we should return a composite layout. |
| Comments |
| Comment by Gerrit Updater [ 07/Apr/22 ] |
|
"John L. Hammond <jhammond@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/47014 |
| Comment by John Hammond [ 07/Apr/22 ] |
|
adilger, paf0186 # lfs setstripe -L mdt -E 1M -E -1 -c 2 . # echo XXXX >> f0 What should the striping be? |
| Comment by Andreas Dilger [ 07/Apr/22 ] |
|
IMHO, the appended file should still be a plain layout file on an OST using the mdd.*.append_* parameters. Using a DoM file for append could cause grief if the file grows very large, as there wouldn't be any way to limit the size. I think this is reasonable and straight forward until/if there is a fix that avoids instantiating all components of an appended file. |
| Comment by Patrick Farrell [ 07/Apr/22 ] |
|
I don't really have an opinion here - Andreas' comment seems reasonable to me. |
| Comment by Gerrit Updater [ 11/Jul/22 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/47014/ |
| Comment by Peter Jones [ 12/Jul/22 ] |
|
Landed for 2.16 |
| Comment by Oleg Drokin [ 15/Jul/22 ] |
|
I feel like |
| Comment by Peter Jones [ 19/Jul/22 ] |
|
green should we try reverting this patch to confirm? |