Are there any tools/approaches to diagnosing and fixing LDM (Logical Disk Manager) metadata structures without recreating from scratch?
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/sdf1 work fine in an mdraid array.
/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:
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:
Physical drives cannot be seen when listing, but can be selected anyway and investigated further. All the actual volumes show up as they should:
but when examined more thoroughly, they seem to be coming from some non-existent disks:
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.