On Fri, Jun 12, 2015 at 02:59:34PM -0500, Tony Asleson wrote:
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 section 29.1.3 Storage
Pool Relocation:
In this profile, storage pool relocation includes: 1) relocating
storage pool onto a new group of extents; 2) merging storage pools.
It seems (19)Relocating is not RAID reconstructing.
Do you see any vendor use that value to indicate reconstructing?
In DMTF definition, "Dormant" indicates that the element
is inactive or quiesced. I think it means STATUS_STOPPED.
I'd better remove that one, and add it back until I see real
implementation.
Hypothetical time line sequence for a failed disk which is fixed
STATUS_OK
...
STATUS_OK | STATUS_DEGRADED
Equal to STATUS_DEGRADED as every degraded is still
accessible.
...
STATUS_OK | STATUS_DEGRADED | STATUS_RECONSTRUCTING
Equal to STATUS_RECONSTRUCTING
as every rebuild is degraded and
accessible.
...
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.
So your suggest:
pros):
1. Leave enough space for future expansion.
cros):
1. No plugin implemented multi-bits status.
2. All multi-bits status could be use single bit status
like I mentioned in 'Summery' section of previous email.
3. User have to check multiple bits to make sure
everything is OK. Every time we add an additional
bit, user code has to add one more check.
For some user, data accessible is not enough to be OK.
So this questions lies to:
Should we design API for future expansion of imaginary products?
# the imaginary products includes SMI-S.
I would say no, once we got real user case where current design
cannot hold, we can bump to next major version.
But I will leave the decision to you. I will change all plugins to
honor that.
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
I prefer documenting
all combinations and their meanings if we
finally choose multi-bits design.
Regards,
Tony
Thank you to the valuable inputs.
Best regards.
--
Gris Ge