Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
I don't suppose you have Microsoft System Center Data Protection Manager, do you? All my googling seems to refer to one of their PowerShell scripts. –  Katherine Villyard Jun 28 '13 at 20:20
    
Unfortunately not, no such service is available in this case (typical separated workstation). My searches did not reveal much either, presumably due to the semi-proprietary nature of the LDM standard. I think not much can be done in this case, but I thought posting here, though a long shot, is my last resort. For the time being, I'm happy that despite this malformed database, all the volumes get recognized by the system and are available for normal use. I hope it stays that way until a more permanent solution can be found (or the problem ceases to exist along with some hardware upgrade). –  Karol Piczak Jun 29 '13 at 23:59
    
I see your Boot drive has a status of Rebuild. Once it completes, see if the error goes away. Also ...did you try a chkdsk on the affected disk to see if it finds anything? –  Nathan C Jun 30 '13 at 22:41

1 Answer 1

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.