On 06/12/2015 12:20 AM, Gris Ge wrote:
Hi Tony,
About the Pool.STATUS_OK we discussed:
* Nstor is always Pool.STATUS_UNKNOWN
* Targetd is always Pool.STATUS_UNKNOWN
* HP is Pool.STATUS_OTHER or STATUS_OK
* SMI-S:
No standard or vendor documentation mentioned possible
combination of OperationalStatus values.
SMI-S 1.6.1r5, Block book, page 95 section 5.2.1
Primary Subsidiary Desc.
Status status
(2) OK The pool is operational
(2) OK (19)Relocating The pool is operational, but
relocation
(3) Degraded Pool is operational, but lower QOS
(3) Degraded (19) Relocating Operational, lower QOS
(6) Error Storage pool is in error
(15) Dormant Non-operational
(15) Dormant (19) Relocating Non-operational & relocating
So yes the SMI-S standard has provision for primary and secondary status.
In my opinion the above SMI-S should be mapped to the library as:
STATUS_OK
STATUS_OK | STATUS_RECONSTRUCTING
STATUS_OK | STATUS_DEGRADED
STATUS_OK | STATUS_DEGRADED | STATUS_RECONSTRUCTING
STATUS_ERROR
STATUS_ERROR | STATUS_STOPPED
STATUS_ERROR | STATUS_STOPPED | STATUS_RECONSTRUCTING
In SNIA Lab, Got HP 3par and Fujitsu DX80S2 only set
DEGRADED value(I cannot tell the reason why they degraded).
The plugin code only handle OK, Degraded, Error in vendor
provided combinations.
I got no hardware to test about grow, reconstruction and etc
right now.
* User cases and plugin implantation:
* RAID degraded, no rebuild.
* ONTAP -- Pool.STATUS_DEGRADE
* MegaRAID -- Pool.STATUS_DEGRADE
* RAID degraded by one disk failure and rebuilding.
* ONTAP -- Pool.STATUS_RECONSTRUCTING
* MegaRAID -- Pool.STATUS_RECONSTRUCTING
* RAID failed (like: two disk failure in RAID 5)
* ONTAP -- Pool.STATUS_ERROR
* MegaRAID -- Pool.STATUS_ERROR
* Verifying RAID integrity.
* ONTAP -- Pool.STATUS_OK
Currently plugin has no idea about it. Need to use
'aggr-mediascrub-list-info' command
* MegaRAID -- Pool.STATUS_OK
Currently plugin has no idea about it. Need to use
'/c0/v1 show cc' command
* Expected -- Pool.STATUS_VERIFYING
* Growing RAID by adding more disks.
* ONTAP -- Pool.STATUS_GROW
* MegaRAID -- Pool.STATUS_OK
Currently plugin has no idea about it. Need to use
'/c0/v1 show migrate' command.
* Creating pool.
* ONTAP -- Pool.STATUS_INITIALIZING
* MegaRAID -- Need test. No idea.
* Pool disabled.
* ONTAP -- Pool.STATUS_STOPPED
* MegaRAID -- Not allowed.
============
Summery:
1. Only SMI-S might(never seen) have multiple status.
2. For degraded rebuilding:
It could express as
Pool.STATUS_RECONSTRUCTING|Pool.STATUS_DEGRADE
But reconstructing always mean degraded, so no need to
have multiple status.
3. For RAID grow:
It could be:
Pool.STATUS_OK | Pool.STATUS_GROW
Online grow
Pool.STATUS_STOPPED | Pool.STATUS_GROW
Offline grow
But we could introduced Pool.STATUS_OFFLINE_GROW also
to keep status as single status.
No existing plugins support offline grow.
So base on above information, I would suggest:
* Keep Pool.status as bit map, but documented that only single status
value will be used right now. Change SMI-S plugin to reflect this.
(Patch is coming soon).
To maintain backwards compatibility all clients would need to treat the
return value as a bitmap. Any other use would cause the client to break
in the future when multiple bits are set. At this point I believe we
should document better and correct the plug-ins to match the documentation.
* Pool.STATUS_OK -- everything is OK.
* Pool.STATUS_DEGRADE -- data accessible but lose redundancy.
I would also advocate that if STATUS_DEGRADED is set that data is at
risk if another failure occurs.
Pool.STATUS_OK | Pool.STATUS_DEGRADED
* Pool.STATUS_ERROR -- data lose or data unavailable.
* Pool.STATUS_RECONSTRUCTING -- data accessible but lose redundancy
and rebuilding data.
They have all the disks for the RAID, but are rebuilding, Data at risk
if they lose another disk during this time.
Pool.STATUS_OK | Pool.STATUS_DEGRADED | Pool.STATUS_RECONSTRUCTING
* Pool.STATUS_STOPPED -- admin or some task disabled data access.
Pool.STATUS_ERROR | Pool.STATUS_STOPPED
* Pool.STATUS_INITIALIZING -- pool creating, data not accessible.
Pool.STATUS_ERROR | Pool.STATUS_INITIALIZING
* Pool.STATUS_GROW -- pool is expanding, data is accessible.
Performance might be impacted(status_info could indicate whether
performance impacted or not).
Pool.STATUS_OK | Pool.STATUS_GROWING
* Pool.STATUS_OTHER -- vendor expansion, check status_info.
Pool.STATUS_OK | Pool.STATUS_OTHER
* Pool.STATUS_VERIFYING -- Running data integrity check. Performance
is impacted. Data is still accessible.
Pool.STATUS_OK | Pool.STATUS_VERIFYING
Hypothetical time line sequence for a failed disk which is fixed
STATUS_OK
...
STATUS_OK | STATUS_DEGRADED
...
STATUS_OK | STATUS_DEGRADED | STATUS_RECONSTRUCTING
...
STATUS_OK
Any comments?
My original design/thought was that if the data was available for r/w
operations and data integrity was ensured that STATUS_OK would be set.
If no additional bits were set then the array believes it is operating
optimally, additional bits indicate additional information which may
effect performance or redundancy or tell more about why the pool is not
accessible.
Client code in my opinion should be something like:
if status == Pool.STATUS_OK:
print("No worries, get outside\n")
else:
if status & Pool.STATUS_OK:
print('Warning... something is sub optimal")
else:
print('We are offline, investigate why')
We should document what are incompatible combinations eg.
STATUS_OK cannot be set with STATUS_ERROR or STATUS_STOPPED
Regards,
Tony