Details
-
Bug
-
Resolution: Fixed
-
Critical
-
Lustre 2.8.0, Lustre 2.9.0, Lustre 2.10.0, Lustre 2.11.0, Lustre 2.10.5
-
None
-
3
-
9223372036854775807
Description
This issue was created by maloo for Andreas Dilger <andreas.dilger@intel.com>
This issue relates to the following test suite run: https://testing.hpdd.intel.com/test_sets/9313c1e0-b06f-11e5-bf32-5254006e85c2.
The sub-test test_82a failed with the following error:
/usr/bin/lfs getstripe -c /mnt/lustre/d82a.conf-sanity/f82a.conf-sanity-1 wrong: found 2, expected 3
Looks like this might be related to running short of precreated OST objects on one of the OSTs and it is skipped rather than blocking the create. The MDS should allow at most 1/4 of requested stripes to be skipped if they have no objects rather than blocking the create indefinitely. However, it appears that this functionality was broken with the change from LOV to LOD, and in this case all 3 OST objects are required since (3 * 1/4 < 1) so no whole stripe could be skipped yet.
In lod_qos_prep_create() it does not set the flags = LOV_USES_DEFAULT_STRIPE for the cases when a filesystem-wide default striping is used as was done in the original qos_prep_create(), and as such lod_alloc_qos() requires that all requested stripes to be allocated. The lod_alloc_qos() code will fall back to lod_alloc_rr() with -EAGAIN if these cannot be allocated. In lod_alloc_rr() it will return success if at least one OST object was allocated, which doesn't seem correct if a large number of stripes was requested, though it isn't clear why lod_alloc_rr() doesn't wait for the OSTs to come online and allocate the requested number of objects.
Also, it looks like the check for lod_qos_is_usable() could be moved to the start of lod_alloc_qos() instead of after the pools are checked, since it doesn't use any of the pool information anyway.
Info required for matching: conf-sanity 82a
Attachments
Issue Links
- duplicates
-
-
- Resolved
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-