[LU-2051] verify lod_alloc_rr() code is doing what we want

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.0
• Fix Version/s: Lustre 2.4.0
• Type: Technical task
• Priority: Critical
• Reporter: Andreas Dilger
• Assignee: Alex Zhuravlev
• Resolution: Fixed
• Story Points: 2

Description

Per comments in http://review.whamcloud.com/4058, we need to have some discussion/investigation on how the lod_alloc_rr() code is behaving under various circumstances. It isn't clear that it is as flexible as the previous lov alloc_rr/osc_precreate behaviour, and this is an area that has needed a lot of tuning in the past to work well under a variety of conditions.

Comments

[Alex Zhuravlev]

any specific concern ?

[Andreas Dilger]

Several previous bugs come to mind:

• ensure that precreate count is scaling with load
• precreate starts early enough so that MDS create doesn't stall
• skip inactive or degraded OSTs
  • ideally ZFS OSD can set this flag itself?
• RR allocation is properly balancing objects on OSTs
• QOS space balance works properly with imbalanced OSTs

I think there are tests foremost of these conditions, but it would be good to verify this.

[Alex Zhuravlev]

Andreas, do you think we still need to do this? there was a patch from Seagate (landed now) where they improved RR and they reported it's now doing much more predictable.

[Andreas Dilger]

The lod_alloc_rr() code itself was fixed to avoid races in updating the state, but it still isn't clear if things like OST object precreation is working optimally (e.g. precreate starts early enough). In particular, there was a benefit shown at LUG a long time ago to start precreate when only 1/4 of the MDS objects were used, rather than waiting until 1/2 were used.

The ZFS DEGRADED flag setting is LU-4277.
The QOS balance and RR balance is LU-9.