https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-217 Lustre <p>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. </p> LU-217

stripe_offset in not used as pool index

Bug Minor Resolved Won't Fix WC Triage Robert Read Sat, 16 Apr 2011 20:27:25 +0000 Wed, 5 Aug 2020 21:54:22 +0000 Wed, 5 Aug 2020 21:54:22 +0000 Lustre 2.0.0 0 1 <p>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).</p> <p>In contrast, the "absolute" OST index never changes, and is well known and displayed in "lfs df" and also "lfs df -p </p> {pool_name} <p>".</p> <p>What is the motivation for this change in behaviour?</p> <p>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. </p> Development Rank 1|hzve4n: Rank (Obsolete) 5928 Severity