[LU-10786] sanity-flr test_45: Create /mnt/lustre/d45.sanity-flr/f45.sanity-flr failed Created: 07/Mar/18 Updated: 08/Jul/19 Resolved: 08/Mar/18 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.11.0 |
| Fix Version/s: | Lustre 2.11.0 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Maloo | Assignee: | James Nunez (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||
| Severity: | 3 | ||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||
| Description |
|
This issue was created by maloo for John Hammond <john.hammond@intel.com> This issue relates to the following test suite run: https://testing.hpdd.intel.com/test_sets/0b6b93ba-21b2-11e8-a6ca-52540065bddc test_45 failed with the following error: Create /mnt/lustre/d45.sanity-flr/f45.sanity-flr failed == sanity-flr test 45: Verify setstripe/getstripe with YAML with FLR file ============================ 01:40:46 (1520386846)
striped dir -i1 -c2 /mnt/lustre/d45.sanity-flr
lfs setstripe: cannot create composite file '/mnt/lustre/d45.sanity-flr/f45.sanity-flr': Invalid argument
sanity-flr test_45: @@@@@@ FAIL: Create /mnt/lustre/d45.sanity-flr/f45.sanity-flr failed
Trace dump:
= /usr/lib64/lustre/tests/test-framework.sh:5382:error()
= /usr/lib64/lustre/tests/sanity-flr.sh:1786:test_45()
= /usr/lib64/lustre/tests/test-framework.sh:5658:run_one()
= /usr/lib64/lustre/tests/test-framework.sh:5697:run_one_logged()
= /usr/lib64/lustre/tests/test-framework.sh:5544:run_test()
= /usr/lib64/lustre/tests/sanity-flr.sh:1799:main()
Dumping lctl log to /home/autotest2/autotest/logs/test_logs/2018-03-06/lustre-reviews-el7-x86_64--review-dne-part-4--1_14_1__55063___be451d59-5222-48cc-8755-8787717407ac/sanity-flr.test_45.*.1520386847.log
CMD: trevis-50vm10,trevis-50vm9,trevis-52vm6.trevis.hpdd.intel.com,trevis-52vm7,trevis-52vm8 /usr/sbin/lctl dk > /home/autotest2/autotest/logs/test_logs/2018-03-06/lustre-reviews-el7-x86_64--review-dne-part-4--1_14_1__55063___be451d59-5222-48cc-8755-8787717407ac/sanity-flr.test_45.debug_log.\$(hostname -s).1520386847.log;
dmesg > /home/autotest2/autotest/logs/test_logs/2018-03-06/lustre-reviews-el7-x86_64--review-dne-part-4--1_14_1__55063___be451d59-5222-48cc-8755-8787717407ac/sanity-flr.test_45.dmesg.\$(hostname -s).1520386847.log
Resetting fail_loc on all nodes...CMD: trevis-50vm10,trevis-50vm9,trevis-52vm6.trevis.hpdd.intel.com,trevis-52vm7,trevis-52vm8 lctl set_param -n fail_loc=0 fail_val=0 2>/dev/null
done.
Also seeing sanity-flr test 46 fail. VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV |
| Comments |
| Comment by Gerrit Updater [ 07/Mar/18 ] |
|
James Nunez (james.a.nunez@intel.com) uploaded a new patch: https://review.whamcloud.com/31569 |
| Comment by Gerrit Updater [ 07/Mar/18 ] |
|
abandoned |
| Comment by Gerrit Updater [ 07/Mar/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/31569/ |
| Comment by Peter Jones [ 07/Mar/18 ] |
|
Landed for 2.11 |
| Comment by Andreas Dilger [ 08/Mar/18 ] |
|
Do people think this will be a usability issue for PFL/DoM files? If the default stripe size is 4MB, but DoM defaults to 1MB max size, then any use of DoM will require the user to explicitly change the stripe size to match the DoM size limit, which is not something that a regular user can directly find out. I think there is already enough complexity in using DoM if the size is changed from the default and this will make it gratuitously difficult for users, to the point that I think it needs to be fixed before the 2.11 release. The simplest option, though not necessarily the best, might be to increase the default DoM limit to 4MB, but I don't think that is optimal for space usage on the MDS. Another option is to have the MDS "fix up" the PFL/DoM layout to reduce the extent end to match the DoM size limit, and shrink the stripe size = extent end of it is larger, or just don't consider that an error. |
| Comment by Peter Jones [ 08/Mar/18 ] |
|
Moving usability discussion to new ticket |
| Comment by Andreas Dilger [ 08/Jul/19 ] |
|
The DoM usability issue was fixed in |