Есть ли способ исправить поврежденную базу данных LDM?

TL; DR:

Есть ли инструменты / подходы к диагностика и исправление LDM (Диспетчер логических дисков) структуры метаданных без воссоздания с нуля?

Полное описание:

У меня есть два SSD-диска, настроенных с помощью GPT + LDM (динамический диск) в состоянии, которое, кажется, подразумевает поврежденная база данных LDM.

Проблема в том, что все работает нормально, за исключением некоторого странного поведения при использовании diskpart или Disk Management Snap-In.

Кажется, что структура GPT не повреждена:

GNU Parted 2.3
Using /dev/sde
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: ATA SanDisk SDSSDP12 (scsi)
Disk /dev/sde: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name                          Flags
 1      17.4kB  1066kB  1049kB               LDM metadata partition
 2      1066kB  134MB   133MB                Microsoft reserved partition  msftres
 3      134MB   47.3GB  47.2GB  ext4         LDM data partition            raid
 4      47.3GB  128GB   80.5GB  ntfs         LDM data partition
 5      128GB   128GB   234MB                LDM data partition

(parted) sel /dev/sdf                                                     
Using /dev/sdf
(parted) print                                                            
Model: ATA SanDisk SDSSDP12 (scsi)
Disk /dev/sdf: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name                          Flags
 1      17.4kB  47.2GB  47.2GB  ext4         LDM data partition            raid
 2      47.2GB  128GB   80.5GB  ntfs         LDM data partition
 3      128GB   128GB   367MB   ntfs         LDM data partition
 4      128GB   128GB   1049kB               LDM metadata partition
 5      128GB   128GB   335kB                Microsoft reserved partition  msftres

/dev/sde3 и /dev/sdf1 отлично работает в массиве mdraid. /dev/sde4 и /dev/sdf2 являются частью зеркального тома Windows. /dev/sdf3 это раздел восстановления Windows. При загрузке в Windows я обычно могу использовать систему и получить доступ к зеркальному системному тому. Однако Disk Management Snap-In сходит с ума:

Фактические физические диски присутствуют без какой-либо информации. Тем не менее, все отдельные тома видны и работают нормально, несмотря на x Метки - SYSTEM (C:) после всего этого отлично выполняет повторную синхронизацию, к нему можно получить доступ, и в настоящее время он используется как системный том.

diskpart подтверждает эту ситуацию:

Физические диски нельзя увидеть при включении в список, но их все равно можно выбрать и изучить дальше. Все фактические объемы отображаются так, как должны:

но при более внимательном рассмотрении кажется, что они исходят от каких-то несуществующих дисков:

Virtual Disk Service error: The disk's extent information is corrupted. похоже, довольно подробно указывает на то, что текущее состояние метаданных LDM больше не соответствует некоторым стандартам Microsoft.

Есть ли способ исследовать это дальше и потенциально исправить эту проблему, не воссоздавая всю схему разбиения диска с нуля? Кажется, мало что можно использовать для диагностики проблем LDM. Я постараюсь получить дамп базы данных прилагается со временем.

Я особенно ищу некоторые подсказки относительно того, на что обращать внимание при анализе База данных LDM.