Ny way to fix a corrupted LDM database

diskpartfilesystemspartedpartition

TL;DR:

Are there any tools/approaches to diagnosing and fixing LDM
(Logical Disk Manager) metadata structures without recreating
from scratch?

Full description:

I have two SSD drives set up with GPT + LDM (dynamic disk) in a state that seems to imply a corrupted LDM database.

The problem is, everything works fine except for some weird behaviour when using diskpart or the Disk Management Snap-In.

The GPT structure seems to be intact:

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 and /dev/sdf1 work fine in an mdraid array. /dev/sde4 and /dev/sdf2 are a part of a Windows mirrored volume. /dev/sdf3 is a Windows recovery partition. When booting into Windows, I can normally use the system and access the mirrored system volume. However, the Disk Management Snap-In goes crazy:
enter image description here

The actual physical drives are present with no information whatsoever. Nevertheless, all the individual volumes can be seen, and function properly despite the x marks – SYSTEM (C:) is doing a fine job re-synchronising after all this, it can be accessed and is currently being used as a system volume.

diskpart confirms this situation:
enter image description here

Physical drives cannot be seen when listing, but can be selected anyway and investigated further. All the actual volumes show up as they should:
enter image description here

but when examined more thoroughly, they seem to be coming from some non-existent disks:
enter image description here

Virtual Disk Service error: The disk's extent information is corrupted. seems to indicate quite verbosely that the current state of the LDM metadata does not conform to some Microsoft standard anymore.

Is there any way to investigate this further and potentially fix this issue without recreating the whole disk partitioning scheme from scratch? It seems there's not much one can use to diagnose LDM issues. I will try to get a database dump attached in due course.

I'm especially looking for some hints as to what to look for when analyzing the LDM database.

Best Answer

Your problem and my problem almost the same: I can see drives in disk management, but non of the partitions were executable, in my windows explorer the drive letters were gone. in my case, disk-part shows everything correctly, and the following method resolved my issue.

Please remove the problematic physical hard drive, attached to another running machine, and run chkdsk with /f /x /c /r, or only /r and /f. Then re-attach, also update your hard disk driver.

Thankyou

Related Topic