[LU-217] stripe_offset in not used as pool index Created: 16/Apr/11 Updated: 05/Aug/20 Resolved: 05/Aug/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.0.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Robert Read (Inactive) | Assignee: | WC Triage |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Rank (Obsolete): | 5928 |
| Description |
|
Currently when a pool_name is specified, the stripe_offset still refers the index of the ost in the global list of OSTs (lov_packed). However, it would make more sense for the stripe_offset to be used as an offset in the pool itself. From a quick reading of the code, I've noticed that at least lov_check_index_in_pool() and alloc_specific() need to be changed. |
| Comments |
| Comment by Andreas Dilger [ 17/Apr/11 ] |
|
The question is what does "offset in the pool" actually mean? There is no separate index assigned to OSTs in a pool, and the relative offset within the pool may change as OSTs are added and removed from the pool (e.g. if there was a pool that had "too empty" OSTs in it). In contrast, the "absolute" OST index never changes, and is well known and displayed in "lfs df" and also "lfs df -p {pool_name}". What is the motivation for this change in behaviour? |
| Comment by Robert Read (Inactive) [ 18/Apr/11 ] |
|
When I first noticed this, it just seemed to be an obvious interpretation of applying stripe_offset to a pool. After further inspection of the code it is clear to me the current behavior is poorly designed (or at best incomplete) - we've made pools a bolt-on hack rather than a first class feature. Done properly, all OST management would be done using pools, rather than maintaining a legacy list for all OSTs, and layering pools on top. |