[LU-13363] unbalanced round-robin for object allocation in OST pool

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.16.0
• Affects Version/s: Lustre 2.14.0
• Environment: Two OST pools with two different sizes of OSTs within the same filesystem
• Severity: 3
• Assignee: Alex Zhuravlev
• Reporter: Shuichi Ihara

Description

Here is an example. create two OST pools with 12 OSTs. pool 'nvme' consists of OST index[0-7].

lctl pool_new scratch.nvme
lctl pool_new scratch.hdd
lctl pool_add scratch.nvme OST[0-7]
lctl pool_add scratch.hdd OST[8-b]

If an client creates 48 files (new files) into an directory which is associated with 8 OSTs by OST pool, it would expect 6 OST objects per OST, but results was totally unbalanced.
Test was repeated 5 times, and here is a result how many OST objects allocated to each OST in each test.

Used 8 of 12 OSTs with an OST pool

      ost index 
    0  1 2 3 4 5  6  7
t1. 4 10 3 8 5 6  8  4
t2. 6  5 6 7 8 4 10  2
t3. 3 10 8 6 5 9  6  1
t4. 4 10 6 5 4 6  8  5
t5. 6  6 7 4 6 5  8  6

If filesystem created on just 8 OSTs and no OST pool, OST objects were allocated to across 8 OSTs in an balanced and round-robin worked perfectly.

Just 8 OST without OST pool

      ost index 
    0 1 2 3 4 5 6 7
t1. 6 6 6 6 6 6 6 6
t2. 6 6 6 6 6 6 6 6
t3. 6 6 6 6 6 6 6 6
t4. 6 6 6 6 6 6 6 6
t5. 6 6 6 6 6 6 6 6

Issue Links

• is related to: LU-9 Optimize weighted QOS Round-Robin allocator
• is related to: LU-9392 lfs migrate -o and lfs setstripe -o should pick OST from ost_list
• is related to: LU-13066 RR vs. QOS allocator should be tracked per OST pool

Comments

[Peter Jones]

Landed for 2.16

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/38136/
Subject: LU-13363 lod: do object allocation in OST pool
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: e642e75cde0248eee30ca94aaeb81653db7f8d03