TOP MAP UP

170127 初版、/gコマンドに終わらない疑惑
170130 SDBBブロックチェインについて追記、いくつかの修正
170131 /gコマンドをスピードアップ。しかし未だに終わらない疑惑。メモ追記
170201 解析でわかった事を追記、/w,/vコマンド追加(主にデバッグ目的)
170210 SDBBの第一、第二パラメータ(可変長)について対応。クラッシュをある程度避けれると思われ
170510 解析でわかった事を追記
170525 解析でわかった事を追記、/hコマンドのSDBBコヒーレンスチェック追加
170531 解析でわかった事を追記、/u /tコマンド追加(主に解析目的)
170606 spaceport.sysについて追記
170609 修理事例の現況を追記
170628 /rコマンド追加、修理事例の現況を追記


Windows 記憶域 / Storage Pool / Storage Space について


WindowsにおけるStorage poolの実装について

※このセクションはかなり想像を含んだ話なので「動作から見て、そんな風に見える」程度に考えて欲しい※

WindowsにおいてStorage Poolは、spaceport.sysというファイルで実装されている。
これはサービスとして稼働しており、以下のようにして、安全に停止/再始動できる
管理者権限にて
sc config spaceport start=disabled
sc config spaceport start=boot

なお、これら一連のファイルはWindowsのProtectedなSystem fileであるため、基本的に消したり改変したりという事が難しくなっている(故に無効化するには上記の方法が安全となる)
またファイルの格納場所もSystem32/driver以外にもWinSxSにも格納されている模様。これらのファイル全てを殺した場合、Windowsその物の起動が拒否される。つまりそれほどにStorage Poolは現時点でのWindowsの中核の機能と言える。

さて、上記手法でStorage Poolを無効化すると、どうなるか?というと、Storage Poolに参加させたディスクは通常ではディスクの管理では見えなくなるが、これが見えるようになる。つまりspaceport.sysは管理の入り口としてフィルタドライバ的な働きをする。

自分がStorage Poolを解析するきっかけになった不具合である「参加させたディスクが何故か見えるようになって参加から外される」という症状だが、
これはspaceportサービスを停止した時と同じように、spaceportの制御下から離れた訳ではなく、ディスクとしてはGPTパーティションテーブル中にStorage Poolの物があり、SPACEDBが存在する時点で、 恐らくspaceportは自分の傘下に明確に置くが、何らかの理由で(これが不具合の原因で、現在調査中)実際の制御を保留されることで、見えるようになる。
ただしこれはあくまで「それ以上はもう触らない」という保留であり、その状態から見えているディスクをオフラインにすることすら出来ない(≒依然としてspaceportの制御下のまま)
この状況になると物理ディスクとしてはセクタリードなどアクセス可能だが、いわゆるPower ShellのStorage Pool関連のphysical diskとしてはlost communicationといった状況になる。 しかし前述のように、本当の意味での物理ディスクとしては全く死んでいない。もちろんSMART値も取れるし、物によっては健全だろう。つまりspaceportのphysical diskとして不整合が生じている・・・というステータスがlost communicationなのだろう。

ディスクの構造:MBRについて

ディスクのセクタ0 = MBR
offsetサイズ内容
0x000446ブートストラップローダ
0x1be1パーティションテーブル0:ブートフラグ
0x1bf3パーティションテーブル0:開始セクタ(CHS)
0x1c21パーティションテーブル0:パーティションタイプ
0x1c33パーティションテーブル0:終了セクタ(CHS)
0x1c64パーティションテーブル0:開始セクタ(LBA)
0x1ca4パーティションテーブル0:総セクタ数
 
0x1ce16パーティションテーブル1
0x1de16パーティションテーブル2
0x1ee16パーティションテーブル3
0x1fe2ブートシグネチャ 0xaa55
GPTディスクでのMBRはお飾り


ディスクの構造:GPTについて

GPTディスクのセクタ1 = GPT
offsetサイズ内容
0x0008シグネチャ
0x0084GPTのバージョン
0x00c4ヘッダサイズ
0x0104ヘッダのCRC32
0x0144reserved
0x0188第1GPTヘッダ位置(LBA)
0x0208第2GPTヘッダ位置(LBA)
0x0288使用可能領域開始位置(LBA)
0x0308使用可能領域終了位置(LBA)
0x03816ディスクのGUID
0x0488パーティションエントリ位置(LBA)
0x0504パーティションエントリ数
0x0544パーティションエントリサイズ
0x0584パーティションエントリのCRC32
0x05creserved
GPTディスクでMBRが書かれている場合があるが、主に互換性を配慮して書かれているので、無くても問題ない

予備領域のパーティションエントリ
offsetサイズ内容
0x00016パーティションタイプGUID : Microsoft Reserved
16 E3 C9 E3,5C 0B B8 4D,81 7D F9 2D,F0 02 15 AE
0x01016パーティションGUID
0x0208開始位置(LBA) : 22
0x0288終了位置(LBA) : 40021
0x0308属性フラグ : 0
0x03872パーティション名 : Microsoft reserved partition
このパーティションは本当に予備領域で、22 - 40800まで、全くデータは書き込まれない
 
storage pool のパーティションエントリ
offsetサイズ内容
0x08016パーティションタイプGUID : storage pool
8f af 5c e7,80 f6 ee 4c,af a3 b0 01,e5 6e fc 2d
0x09016パーティション
0x0A08開始位置(LBA) : 40800
0x0A88終了位置(LBA)
0x0B08属性フラグ : 0
0x0B872パーティション名 : 記憶域プール


ディスクの構造:StoragePoolについて

storage poolパーティションの中のうち SPACEDB
offsetサイズ略称内容
0x0008シグネチャ : "SPACEDB "
0x0082P1記憶域のGUID位置(paragraph unit/bigendian)
0x00a2SPACEDBの長さ(byte unit/bigendian)
0x00c4SPACEDBのCRC32(bigendian)
ディスク毎に異なる
??謎のデータが入る場合がある
ディスク毎に異なる
P1*0x10+0x0016記憶域のGUID
P1*0x10+0x1016SPACEDBのGUID
ディスク毎に異なる。SPACEDBにおけるphysical disk GUID的な物
0x040??
開始位置は基本0x40800=264192
アクセスは以降4Kセクタ扱いで行われる

storage poolパーティションの中のうち SDBC
offsetサイズ略称内容
0x0008シグネチャ : "SDBC "
0x0082P1記憶域のGUID位置(paragraph unit/bigendian)
基本1
0x00a2SDBCの長さ(byte unit/bigendian)
0x00c4SDBCのCRC32(bigendian)
??謎のデータが入る場合がある
P1*0x10+0x0016記憶域のGUID
P1*0x10+0x104?
P1*0x10+0x144V1SDBB start position
SDBB開始セクタ位置=40801+(V1/8)
P1*0x10+0x184V2SDBB length
SDBB終了セクタ位置=SDBB開始セクタ位置+(V2/8)-1
-1は0位置も長さに含むので
P1*0x10+0x1CC??
P1*0x10+0x288V3コマンドのシリアルナンバー
P1*0x10+0x308V4コマンドのシリアルナンバー
P1*0x10+0x384??
P1*0x10+0x3C4V5SDBBのCRC32(bigendian)
位置は基本SPACEDB+8の0x40808=264200
SDBCが無い=SDBBも無い
SDBCのコマンドシリアルナンバーが一番大きいものがcurrentのSDBC

storage poolパーティションの中のうち SDBB
offsetサイズ内容
0x0004シグネチャ : "SDBB"
0x0044現在のSDBBブロックでの位置(8始まり=SDBCからの位置)(bigendian)
0x0084現在のSDBBブロックは、どのSDBBブロックからのチェインか(bigendian)
ここがゼロの場合はそのSDBBは未使用と考えられる?
0x00c2現在のSDBBブロックチェイン上の位置(0始まり、n-1終わり)(bigendian)
0x00e2現在のSDBBブロックチェインのサイズ(ブロック単位、↑のn)(bigendian)
0x01048データ?
SDBBブロックアドレスはSDBCからの0x40byte単位で表現
サイズが2ブロックの場合は、現在位置,開始位置,チェイン上の現在位置,チェインのサイズ - 08,08,00,02 - 09,08,01,02 という表現になる
この部分の長さはディスク毎に異なる場合がある

SDBBの中の SDBBブロックチェイン
offsetサイズ略称内容
0x000101 : 記憶域の情報
0x00130D 00 00 : 謎
0x0044L1データ長(byte) 全体のデータ長
0x0081L2データ長(byte)
-L2D2データ
-1L3データ長(byte)
-L3D3コマンドのシリアルナンバー
-16記憶域のGUID
-2L4記憶域名の長さ(short)
-L4 x shortD4記憶域名(wide文字、null終端)
-1000 00 00 04 13 0C 0C 46 01 01 : 謎
-1D5データ
-1D6ProvisioningTypeDefault
01 : thin
02 : fixed
unknownは設定できず
-1L7データ長(byte)
-L7D7データ
-400 01 01 02 : 謎
-1L8データ長(byte)
-L8D8データ
-200 00 : 謎
-1L9データ長(byte)
-L9D9データ(非常に長い)
-601 00 01 01 01 01: 謎
-1LAデータ長(byte)
-LADAデータ
-812 02 01 01 01 02 01 01: 謎
-1LBデータ長(byte)
-LBDBデータ
-612 03 01 01 01 01: 謎
-1LCデータ長(byte)
-LCDCデータ
-1LDデータ長(byte)
-LDDDデータ
-?12 : 謎
 
offsetサイズ略称内容
0x000102 : storage poolに参加しているphysical diskの情報
0x0013
0x0044L1データ長(byte) 全体のデータ長
0x0081L2データ長(byte)
-L2D2physical disk number ?
-1L3データ長(byte)
-L3D3コマンドのシリアルナンバー
-16SPACEDBのGUID
ディスク毎に異なる。SPACEDBにおけるphysical disk GUID的な物
-2L4physical diskのフレンドリ名の長さ(short)
-L4 x shortD4physical diskのフレンドリ名(wide文字、null終端)
-300 00 00 : 謎
-1D5SDBB
00 : old or missing
02 : current
-1D6Usage
00 : Auto-Select表示だが、実際には何かしらのエラーがある
01 : Auto-Select (default)
02 : Manual-Select
03 : Hot Spare
04 : Journal
05 : Retired
Unknownは設定できず
-1D7Media Type
00 : Unspecified
01 : HDD
-1L8データ長(byte)
-L8D8?
-1L9データ長(byte)
-L9D9?
D7=D8+2が典型
 
offsetサイズ略称内容
0x000103 : storage poolで作成しているボリュームの情報
0x0013
0x0044L1データ長(byte) 全体のデータ長
0x0081L2データ長(byte)
-L2D2データ
-1L3データ長(byte)
-L3D3コマンドのシリアルナンバー
-16ボリュームのGUID
-2L4ボリューム名の長さ(short)
ボリューム名長さがゼロの場合は当該chainは削除され無効となったものと判断
-L4D4ボリューム名(wide文字、null終端)
-500 00 00 00 02 : 謎
-1L5データ長(byte)
-L5D5データ
-1L6データ長(byte)
-L6D6データ
-1D7ProvisioningType
01 : thin
02 : fixed
-904 10 00 00 00 00 01 01 00 : 謎
-1D8ResiliencySettingName
01: Simple
02 : Mirror
03 : Parity
-1L9データ長(byte)
-L9D9データ
-101 : 謎
-1D10number of copies
-301 01 01 : 謎
-1D11number of clumns
--12 04 02 : 謎
 
offsetサイズ略称内容
0x000104 : スラブ割り当て情報
0x0013
0x0044L1データ長(byte) 全体のデータ長
0x0081L2データ長(byte)
-L2D2データ
-1L3データ長(byte)
-L3D3コマンドのシリアルナンバー
-600 00 01 01 01 06 : 謎
-1L4データ長(byte)
-L4D4データ
-1L5データ長(byte)
-L5D5virtual disk number
-1L6データ長(byte)
-L6D6データ
-1L7データ長(byte)
-L7D7データ
-1L8データ長(byte)
-L8D8physical disk number
-1L9データ長(byte)
-L9D9slab number
 

メモ:ディスクの使用属性(Usage)
Auto Select
Hot Sparet
Journal
Manual Select
Retired
Unknown

メモ:記憶域プールの利用属性(Usage)
Other (default)
ReservedAsDeltaReplicaContainer
ReservedForComputerSystem
ReservedForLocalReplicationServices
ReservedForMigrationServices
ReservedForRemoteReplicationServices
ReservedForSparing
Unrestricted

メモ:記憶域スペースの論理セクターサイズ
512byte
4096byte
記憶域プールでデフォルト値を保持

メモ:記憶域スペースの利用属性(Usage)
Other
ReservedAsDeltaReplicaContainer
ReservedForComputerSystem
ReservedForLocalReplicationServices
ReservedForMigrationServices
ReservedForRemoteReplicationServices
ReservedForSparing
Unrestricted


メモ

※一般的メモ※
上記データフォーマットは解析が進んだ場合、略称が再度振りなおされたり改訂されたりするので注意
CRC32計算の初期値はゼロとする。
自己を含む各箇所のCRC32の計算中は、その個所をゼロとして計算される



※Storage Poolメモ※
記憶域プール = storage pool = chain 01 = ディスクの集合体
記憶域スペース = storage space = chain 03 = 記憶域プールから作ったディスクボリューム
ディスクをstorage poolから離脱したとしても、GPTパーティションエントリの情報が書き換わるだけで、storage poolそのものの情報は残っている。
ただし離脱前に、ディスクの内容を他に移動させるはずなので、中身的には空になっていると思われるが・・・。
数値が基本的にbigendianで格納されているが、文字列のUTF-16についてもhighbyte/lowbyteのスワップが必要
公の記事ではスラブ=256MBの倍数となる。何倍になるかはまだ良くわかっていない



※Storage Pool SDBCメモ※
SDBCが存在しない場合、SDBBも存在しない。ただしSPACEDBは存在する。



※Storage Pool SDBB chainメモ※
SDBBは恐らくStorage Poolに参加しているディスクの容量などを参考に、最大5程度のドライブに、同一内容のものが保持される。
同一内容であるかは、SDBCのコマンドシリアライズ値などで確認されると思われる。
故にディスクの増減によって「昔はSDDBが書かれていたが、現在は書かれていない」といったパターンの場合に古いSDDBが残る

データ長さが0の場合、データが無いのではなく、データ値は0となる模様
コマンドシリアルナンバーは、各コマンド(01,02,03,04)毎にシリアライズされる模様
chainの01/02/03/04の出現順位はバラバラ。chainの連続性は、現在の所、不連続は確認されてないが、連続するとは限らない




AZUCO Storage Pool Toolについて

わかる限りでStorage Poolの整合性を確認しながら、情報を出力するツール。
Win32 コンソールプログラム 32/64bit
コンパイルにはzlibが必要です

本ツールはかなり危険なツールですので、一切が無保証という前提で使用お願いします。

また記憶域を解析することで判明した情報をお寄せいただければプログラムの方にフィードバックいたします(多分w)



オプション書式内容
/aphysical diskを列挙します。確からしいセクタサイズを表示します。
要管理者権限
/b[physical disk number]指定のphysical diskのMBRの内容を表示します。
要管理者権限
/c[physical disk number]指定のphysical diskのGPTの内容を表示します。
要管理者権限
/d[physical disk number]指定のphysical diskのGPTパーティションの内容を表示します。
要管理者権限
/e[physical disk number]指定のphysical diskのSPACEDBの内容を表示します。記憶域参加のディスクに限る。
要管理者権限
/f[physical disk number]指定のphysical diskのSDBCの内容を表示します。記憶域参加のディスクに限る。
要管理者権限
/g[physical disk number]指定のphysical diskのSDBBの内容を表示します。記憶域参加のディスクに限る
チェインの連続性を期待しないので、SDBBを総ざらいするため時間がかかります。
要管理者権限
/hSDBBのチェックを行います。SDBBのシリアライズ値で、どのドライブのSDBBが現在使われているのかを確認
SDBBのコヒーレンスチェックを行います。
要管理者権限
 
/r[physical disk number]指定のphysical diskのSDBC-SDBBをゼロクリアする
要管理者権限、要spaceport.sysサービス停止
/s[physical disk number]指定のphysical diskのSDBC-SDBBにカレントフォルダのspacedb_xx.binの内容を書き込みます。
要管理者権限、要spaceport.sysサービス停止
/t[physical disk number]指定のphysical diskの予備領域(22-40800セクタ)をカレントフォルダのreserve_xx.binに出力します。
要管理者権限
/u[physical disk number]指定のphysical diskのSDBC-SDBBの内容ををカレントフォルダのspacedb_xx.binに書き込みます。
要管理者権限
/v/gコマンドにおけるSDBB chain表示のうち、03のボリューム名長さがゼロの物を表示する
/w/gコマンドにおけるSDBB chain表示のうち、04の物を表示しない
/x[physical disk number],[sector/HEX]指定のphysical diskの指定のセクタをダンプします。
要管理者権限
/y[physical disk number]指定のphysical diskの確からしいセクタサイズを自動セットします。
要管理者権限
/z[sector size switch]sector size switchが
4 = セクタサイズは4096(4K)になります
それ以外はセクタサイズは512になります
 
オプションは続けて記述できます。
例) aspt /z4 /x1,40800



DOWNLOAD : ASPT r170628



修理事例 : AZUCOのホームサーバ

170202:見やすいように省略

障害内容 記憶域プールから離脱したつもりはないが、いつの間にやらHDDが1台離脱していた。これをなんとか戻したい。

この時点では個々の情報では特に不整合は見られなかった
一部SDBBの内容に違いが見られたが、この時点では「SDBBは個々のディスク毎の記録なのだろう=違ってて当然」という認識だった
結論的には「もっと解析しないとわからないね」という状況であった(汗

170609

PowerShellにおけるget-physicaldiskの状況は以下の通り
FriendlyName                          SerialNumber    CanPool OperationalStatus  HealthStatus Usage            Size
------------                          ------------    ------- -----------------  ------------ -----            ----
WDC WD40EZRX-00SPEB0                  WD-WCC4E1950536 False   OK                 Healthy      Auto-Select   3.64 TB
ST8000AS0002-1NA17Z                                   False   Lost Communication Warning      Auto-Select   7.28 TB
ST8000AS0002-1NA17Z                   Z840J2JR        False   OK                 Healthy      Auto-Select   7.28 TB
WD 2TB BAD                            WD-WCAVY2549847 False   OK                 Healthy      Auto-Select   1.82 TB
WDC WD10EADS-00L5B1                                   False   Lost Communication Warning      Auto-Select  931.5 GB
I-O DATA HDH-USR USB Device           WD-WCAV33280536 False   OK                 Healthy      Auto-Select    149 GB
WDC WD30EZRX-00DC0B0                  WD-WMC1T1341838 False   OK                 Healthy      Auto-Select   2.73 TB
WDC WD30EZRX-00DC0B0                  WD-WMC1T0679272 False   OK                 Healthy      Auto-Select   2.73 TB
HGST HMS5C4040ALE640 SATA Disk Device PL1331LAGNL4GH  False   OK                 Healthy      Auto-Select   3.64 TB
WDC WD30EZRX-00DC0B0                  WD-WMC1T0951531 False   OK                 Healthy      Auto-Select   2.73 TB
WDC WD20EARS-00MVWB0                  WD-WCAZA6313565 False   OK                 Healthy      Auto-Select   1.82 TB
ST8000AS0002-1NA17Z                   Z840A7LA        False   OK                 Healthy      Auto-Select   7.28 TB
ST4000DM000-1F2168                                    False   Lost Communication Warning      Auto-Select   3.64 TB
TOSHIBA THNSNH128GCST                 43HS10M8TPEY    False   OK                 Healthy      Auto-Select 119.24 GB
WDC WD40EZRX-00SPEB0                  WD-WCC4ERYTP8E0 False   OK                 Healthy      Auto-Select   3.64 TB
このOperationStatusであるLost Communicationが直接的な障害となっている。
なおasptでセクタリードが出来ているので、本当の意味でのディスクに対するアクセスは問題なくできている。
つまりこれはspaceport.sys的にLost Communicationしているに過ぎない。

この状況でのSDBCの使用状況と、SDBBのコヒーレンスチェックは以下の通り
SDBB check
PD      serial value                            sector  status
00      0000000000000000000000000005DA05        0512    current
01      000000000000000000000000000586B1        0512    old
02      0000000000000000000000000005843E        0512    old
03      00000000000000000000000000000000        0512    missing or invalid
04      0000000000000000000000000005BBBE        0512    old
05      00000000000000000000000000058AE2        0512    old
06      00000000000000000000000000000000        0512    missing or invalid
07      00000000000000000000000000058434        0512    old
08      0000000000000000000000000005D9EB        0512    old
09      00000000000000000000000000054C37        0512    old
10      00000000000000000000000000057B2A        0512    old
11      0000000000000000000000000005DA05        0512    current
12      0000000000000000000000000005DA05        0512    current
13      00000000000000000000000000058AE5        0512    old
14      0000000000000000000000000005DA05        0512    current

SDBB coherence check
PD      PD      incoherence sector
この結果におけるstatusというのは、あくまでSDBBのシリアル値から求めた「多分これが最新なんじゃないか」というSDBBの存在するドライブをcurrentとしている。
この状況でのcurrentであるドライブのSDBBのコマンド02(physical disk情報)は以下の通り
command 02
Pn Cn                   L1 L2 D2 L3 D3       SPACEDB                                    GUID L---4 Name                       D5 D6 D7 L8 D8    L9 D9
00 02 05 00 00 00 00 00 4E 01 3B 03 05 8A E1 13 98 27 D0 D7 FA 91 E9 17 96 C5 4D 88 BF 13 31 00 15 00 57 00 .. 00 00,00 00 00 02 01 00 02 3A 38 02 3A 35
01 02 05 00 00 00 00 00 70 01 30 03 05 86 6D 82 30 8A F0 E6 71 EF C7 75 0D 0C 56 7D C4 BA A7 00 26 00 48 00 .. 00 00,00 00 00 00 01 00 02 3A 38 02 3A 35
02 02 05 00 00 00 00 00 4E 01 11 03 05 D9 EA 84 A7 8D D0 2A FB 11 E2 BE 80 80 6E 6F 6E 69 63 00 15 00 57 00 .. 00 00,00 00 00 00 01 00 02 1F FF 02 2B A7
03 02 05 00 00 00 00 00 5C 01 53 03 05 D9 2F 3F D5 77 92 7A 7C C6 FF 74 56 9D 59 1B A6 A3 6E 00 1C 00 49 00 .. 00 00,00 00 00 00 01 00 02 02 54 02 02 51
04 02 05 00 00 00 00 00 4E 01 08 03 05 D9 E9 7D 86 D5 3B 23 3E 11 E2 BE 72 80 6E 6F 6E 69 63 00 15 00 57 00 .. 00 00,00 00 00 00 01 00 02 2B AA 02 2B A7
05 02 05 00 00 00 00 00 4E 01 47 03 05 8A E2 C8 3E DB BD 2D 3E 11 E2 BE 87 80 6E 6F 6E 69 63 00 15 00 57 00 .. 00 00,00 00 00 00 01 00 02 1D 1C 02 1D 19
07 02 05 00 00 00 00 00 4E 01 48 03 05 D9 E8 4C 24 4B AC 46 B9 11 E2 BE 74 80 6E 6F 6E 69 63 00 15 00 57 00 .. 00 00,00 00 00 00 01 00 02 2B AA 02 2B A7
08 02 05 00 00 00 00 00 4C 01 4A 03 05 8A DF 1E 37 F3 39 C2 C8 7C 81 49 C8 00 61 C7 D3 02 60 00 14 00 53 00 .. 00 00,00 00 00 02 01 01 02 74 70 02 74 6D
09 02 05 00 00 00 00 00 4E 01 3F 03 05 72 B2 EE 95 B2 13 8E 65 BB 8D 2C 7B 21 49 8B 3A A9 ED 00 15 00 57 00 .. 00 00,00 00 00 00 01 00 02 3A 38 02 3A 35
10 02 05 00 00 00 00 00 4C 01 46 03 05 7B 2A D3 CB 34 F9 6D 80 F5 BC DA 59 39 5C 0D 8A 78 EC 00 14 00 53 00 .. 00 00,00 00 00 00 01 00 02 74 70 02 74 6D
11 02 05 00 00 00 00 00 4A 01 24 03 05 8A D9 DF E7 A1 B4 E3 11 11 E2 BE 9E 80 6E 6F 6E 69 63 00 13 00 53 00 .. 00 00,00 00 00 02 01 00 02 3A 38 02 3A 35
12 02 05 00 00 00 00 00 4C 01 52 03 05 BB BD 17 29 76 A9 78 3F 4F B0 1E 9F C5 FE FE 20 74 57 00 14 00 53 00 .. 00 00,00 00 00 02 01 01 02 74 70 02 74 6D
13 02 05 00 00 00 00 00 3A 01 49 03 05 D9 EB 2B 95 6B 3D 34 0D 11 E2 BE A2 80 6E 6F 6E 69 63 00 0B 00 57 00 .. 00 00,00 00 00 00 01 00 02 1D 1C 02 1D 19
14 02 05 00 00 00 00 00 4C 01 4D 03 05 8A DB 37 58 82 62 92 87 30 F4 EA 3A 76 E0 CF BF E1 8D 00 14 00 57 00 .. 00 00,00 00 00 02 01 00 02 0E 8E 02 0E 8B
この情報で見ると、ディスク08のD5は02になっており、多分これも本来はcurrentだったのではないか?と予測できる。
ようやく不整合らしき不整合を発見できた訳だ

ということで、個々のディスク毎に内容の異なるSPACEDB(=これがspaceport.sysにおける実質的なphysical diskとして扱われる所)はそのままで、 とりあえず、その後のSDBC-SDBBをexport/inportする機能を付けてみた。
※安全のため、全てのドライブのexportを行っておくのが良いかもしれない※
※inportは非常に危険なコマンドなので、十分に考えてから使用する事※
※export/inportはファイル名固定なので、inportする場合は、元のデータはリネームなどで保持しておくのをお勧めする※
※inportはファイル全てを書き込むので、SDBBの直後に実データが入っている場合は、それを破壊してしまうので、事前に確認しておくこと※
※inportする際は、spaceport.sysの動作を停止する事※

inportした後に、再度spaceport.sysを有効にして再起動すると、ディスクの管理で見えていたディスクが見えなくなる。つまりこれはsparceport.sysのある程度制御下に入ったものと思って差し支えないだろう。
なおこの状況でのPowerShellにおけるget-physicaldiskの状況は以下の通り
FriendlyName          SerialNumber    CanPool OperationalStatus HealthStatus Usage            Size
------------          ------------    ------- ----------------- ------------ -----            ----
WDC WD40EZRX-00SPEB0  WD-WCC4E1950536 False   Starting          Unknown      Unknown       3.64 TB
ST8000AS0002-1NA17Z   Z840Q1FX        False   Starting          Unknown      Unknown       7.28 TB
ST8000AS0002-1NA17Z   Z840J2JR        False   Starting          Unknown      Unknown       7.28 TB
WDC WD20EARS-00S8B1   WD-WCAVY2549847 False   Starting          Unknown      Unknown       1.82 TB
WDC WD10EADS-00L5B1   WD-WCAU45692790 False   Starting          Unknown      Unknown     931.51 GB
WDC WD1600AAJS-19M0A0 WD-WCAV33280536 False   Starting          Unknown      Unknown     149.05 GB
WDC WD30EZRX-00DC0B0  WD-WMC1T1341838 False   Starting          Unknown      Unknown       2.73 TB
WDC WD30EZRX-00DC0B0  WD-WMC1T0679272 False   Starting          Unknown      Unknown       2.73 TB
HGST HMS5C4040ALE640  PL1331LAGNL4GH  False   Starting          Unknown      Unknown       3.64 TB
WDC WD30EZRX-00DC0B0  WD-WMC1T0951531 False   Starting          Unknown      Unknown       2.73 TB
WDC WD20EARS-00MVWB0  WD-WCAZA6313565 False   Starting          Unknown      Unknown       1.82 TB
ST8000AS0002-1NA17Z   Z840A7LA        False   Starting          Unknown      Unknown       7.28 TB
ST4000DM000-1F2168    Z300E76D        False   Starting          Unknown      Unknown       3.64 TB
TOSHIBA THNSNH128GCST 43HS10M8TPEY    False   OK                Healthy      Auto-Select 119.24 GB
WDC WD40EZRX-00SPEB0  WD-WCC4ERYTP8E0 False   Starting          Unknown      Unknown       3.64 TB
このようにLost Communicationではなくなる。つまりLost Communicationとは、SDBBに書かれたSDBB currentステータスと実態が乖離した場合に発生する症状であると思われる
ただし、この状況になってもStorage Poolそのものが再開する訳ではない。つまり、まだどこかに不整合があると判断されているものと思われる
ちなみにこの状況は、逆順で元のSDBBを書き込んでやれば、元の状況に戻る(そういう意味でも、全部のドライブのエクスポートをお勧めする)

170628

任意のディスクのSDBC-SDBBを全部クリアするという機能を実装し(この機能を使う際は、元のデータをexportしておく方が良い)
lost communicationになっているディスクにそれを適用、かつcurrentのSDBBのcurrentをmissingにして整合性を取るという、処理を施した。
FriendlyName                          SerialNumber    MediaType   CanPool OperationalStatus     HealthStatus Usage            Size
------------                          ------------    ---------   ------- -----------------     ------------ -----            ----
WDC WD40EZRX-00SPEB0                  WD-WCC4E1950536 Unspecified False   OK                    Healthy      Auto-Select   3.64 TB
ST8000AS0002-1NA17Z                   Z840Q1FX        HDD         False   Unrecognized Metadata Unhealthy    Unknown       7.28 TB
ST8000AS0002-1NA17Z                   Z840J2JR        HDD         False   OK                    Healthy      Auto-Select   7.28 TB
WD 2TB BAD                            WD-WCAVY2549847 Unspecified False   OK                    Healthy      Auto-Select   1.82 TB
WDC WD10EADS-00L5B1                   WD-WCAU45692790 Unspecified False   OK                    Healthy      Auto-Select  931.5 GB
WDC WD1600AAJS-19M0A0                 WD-WCAV33280536 Unspecified False   Unrecognized Metadata Unhealthy    Unknown     149.05 GB
WDC WD30EZRX-00DC0B0                  WD-WMC1T1341838 Unspecified False   OK                    Healthy      Auto-Select   2.73 TB
WDC WD30EZRX-00DC0B0                  WD-WMC1T0679272 Unspecified False   OK                    Healthy      Auto-Select   2.73 TB
HGST HMS5C4040ALE640 SATA Disk Device                 Unspecified False   Lost Communication    Warning      Auto-Select   3.64 TB
WDC WD30EZRX-00DC0B0                  WD-WMC1T0951531 Unspecified False   OK                    Healthy      Auto-Select   2.73 TB
WDC WD20EARS-00MVWB0                  WD-WCAZA6313565 Unspecified False   OK                    Healthy      Auto-Select   1.82 TB
ST8000AS0002-1NA17Z                   Z840A7LA        Unspecified False   OK                    Healthy      Auto-Select   7.28 TB
ST4000DM000-1F2168                    Z300E76D        Unspecified False   OK                    Healthy      Auto-Select   3.64 TB
TOSHIBA THNSNH128GCST                 43HS10M8TPEY    SSD         False   OK                    Healthy      Auto-Select 119.24 GB
WDC WD40EZRX-00SPEB0                  WD-WCC4ERYTP8E0 Unspecified False   OK                    Healthy      Auto-Select   3.64 TB
今までlost communicationだったものが、Unrecognized Metadataになっている。
ちなみにこの状況だと、一応ディスク的にはreadyに見える。
この状況が進展したかどうかはよくわからないのだが、想像するにSPACEDBの謎の部分がMetadataへの位置を示すものなのではなかろうか。