On Thu, Apr 16, 2015 at 04:56:55PM -0500, Tony Asleson wrote:
Hi Gris,
Initial overall comments, individual code comments on github. Need to
try it out on some hardware.
On 04/16/2015 10:05 AM, Gris Ge wrote:
> * New method `pool_raid_info()` to query pool member information:
> * RAID type
> * Member type: disk RAID pool or sub-pool.
> * Members: disks or parent pools.
This function is named similar to the volume_raid_info, but it
returns entirely different data. Should we rename it to
pool_member_info so if we add a method to return data similar to
volume_raid_info the naming scheme won't be confusing?
Yeah. Make sense, I will
change it pool_member_info.
> * Design notes:
> * Why we need pool_raid_info() when we already have volume_raid_info()?
> The `pool_raid_info()` is focus on RAID disk or sub-pool layout.
What is the use case for pool_raid_info?
Initially, I just want to make sure the
changes made by
volume_create_raid() is queryable and also suitable for SAN/NAS.
Other use case:
* Query pool data availability(RAID),
performance(disk type, RAID type, disk count).
* Call pool_member_info().
* If got Pool.MEMBER_TYPE_POOL, query parent pool.
* Call disks() to get disk type. [1]
[1] Maybe we could find a way to expose disk property of
rotation per minute, link speed and etc.
--
Gris Ge