Re: [Linux-NTFS-Dev] Windows 7 Dynamic Disks and LDM

[Anton A. <ai...@ca...>]

Hi,

On 21 Jul 2012, at 03:24, Carl-Daniel Hailfinger wrote:
> Hi Anton,
> 
> wow! Thanks for investigating this in detail.

You are welcome.

> Am 21.07.2012 03:25 schrieb Anton Altaparmakov:
>> I created one to have a look myself so no need to send me anything.
>> 
>> It looks like this:
>> 
>> Sector zero is a standard protective MBR/MSDOS style partition table with just one partition of type 0xEE (protective) which covers whole disk.
>> 
>> Then there is a full GPT partition table (what Linux calls EFI though that is a misnomer) which contains three partitions.  The LDM database partition which is exactly 2048 sectors in size (sector size 512 bytes).  The UUID for that is 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3.  That is followed by the microsoft reserved partition which we can ignore as it is just reserved space.  And that is followed by the ldm data partition which stores the actual volumes/volume fragments.  The UUID for that is AF9B60A0-1431-4F62-BC68-3311714A69AD.
>> 
>> Then there are a few other difference between LDM on MBR and GPT.
>> [...]
>> Looks like the right solution will be to hook into the efi.c code in the kernel and check the found GPT partition UUIDs and when a LDM database partition is found call into the LDM code and there we need to make some changes to allow for the above described differences and then it will probably start working...
> 
> I could try to hook up the LDM code to the GPT code. I have hacked on
> the kernel partitioning code in the past, it would be fun to revisit
> that. My experience with LDM internals is zero, though, so I'll probably
> hit a roadblock eventually.

Sounds good.  Feel free to direct questions at me.  I will send you an attachment off list with the latest ldm documentation (much more complete than the one on SF.net - I will update the one on SF.net with this one but I am just waiting to hear back from the person who updated it).

> AFAICS the LDM partition code is called before the MSDOS/MBR partition
> code, but after the GPT partition code (see
> block/partitions/check.c:check_part[]).

Correct.

> If I understood your suggestion correctly to hook into the efi.c code, the detection of LDM on GPT would happen in a way that's different from how LDM is detected on MSDOS/MBR.
> Is that what you meant?

Yes.  I would stick it inside block/partitions/efi.c::efi_partition() something like this:

#ifdef CONFIG_LDM_PARTITION
	u64 ldm_db_start, ldm_db_size, ldm_data_start, ldm_data_size;
	bool is_ldm = false;
	bool skip_ldm = false;
#endif /* CONFIG_LDM_PARTITION */

	[snip]

#ifdef CONFIG_LDM_PARTITION
retry:
#endif /* CONFIG_LDM_PARTITION */

	for (i = 0; i < le32_to_cpu(gpt->num_partition_entries) && i < state->limit-1; i++) {
                struct partition_meta_info *info;
                unsigned label_count = 0;
                unsigned label_max;
                u64 start = le64_to_cpu(ptes[i].starting_lba);
                u64 size = le64_to_cpu(ptes[i].ending_lba) -
                           le64_to_cpu(ptes[i].starting_lba) + 1ULL;

                if (!is_pte_valid(&ptes[i], last_lba(state->bdev)))
                        continue;

#ifdef CONFIG_LDM_PARTITION
		/*
		 * LDM can be both on MBR and GPT partitioning scheme.
		 *
		 * We deal with MBR based LDM later on but we need to deal with
		 * GPT based LDM now.
		 */
		if (!skip_ldm) {
        	        if (!i && !efi_guidcmp(ptes[i].partition_type_guid,
	                                 PARTITION_LDM_DATABASE)) {
				ldm_db_start = start;
				ldm_db_size = size;
				is_ldm = true;
				continue;
			} else if (is_ldm) {
				int ret;

				/*
				 * We need to skip partitions until we find the LDM
				 * data partition.
				 */
				if (efi_guidcmp(ptes[i].partition_type_guid,
                        			PARTITION_LDM_DATA))
					continue;
				ret = ldm_gpt_partition(state, ldm_db_start,
					ldm_db_size, start, size);
				if (ret == 1) {
					kfree(ptes);
					kfree(gpt);
					return ret;
				}
				/*
				 * ldm_gpt_partition() failed.  Might as well treat the disk as
				 * non-LDM / normal GPT.
				 */
				is_ldm = false;
				skip_ldm = true;
				goto retry;
			}
		}
#endif /* CONFIG_LDM_PARTITION */

                put_partition(state, i+1, start * ssz, size * ssz);

		[snip]
	}

#ifdef CONFIG_LDM_PARTITION
	/*
	 * If we found an LDM database partition but no matching LDM data partition
	 * there is something very odd going on.  Log a message and re-process the
	 * partitions as non-LDM.
	 */
	if (is_ldm) {
		printk(KERN_WARNING "LDM database partition found on GPT disk "
				"but no matching LDM data partition found.  "
				"Ignoring LDM database partition.\n");
		is_ldm = false;
		skip_ldm = true;
		goto retry;
	}
#endif /* CONFIG_LDM_PARTITION */

Then in efi.h put in constants for the PARTITION_LDM_DATABASE 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3 and the PARTITION_LDM_DATA AF9B60A0-1431-4F62-BC68-3311714A69AD and of course add a function to ldm.c (and efi.h I guess!) something like that:

int ldm_gpt_partition(struct parsed_partitions *state, const u64 ldm_db_start, const u64 ldm_db_size, const u64 ldm_data_start, const u64 ldm_data_size)...   Then that function can do all the LDM specific bits and add the devices with put_partition(), etc.  The only reason I both with the ldm_data_start and ldm_data_size is so it can be cross checked with

Or something like that anyway.  This is a bit ifdef ugly but I can't see a neater way of doing it without having to re-read the GPT in the ldm driver itself (and obviously moving the ldm driver to before efi.c in check.c).

> There is also the question of naming the devices... hiding all GPT
> partitions is a bit inconvenient if someone wants to access the GPT BIOS
> Boot Partition or the GPT EFI System Partition (e.g. for installing a
> bootloader). Device names like hdXldmN (hdaldm1) instead of hdXN (hda1)
> are really clumsy, but I don't have a better suggestion.

Not really. I doubt you would ever have a GPT BIOS partition or a GPT EFI System partition on a Windows Dynamic Disk.  The only partitions are the LDM database partition, the Microsoft reserved partition, and the LDM data partition which covers the entire disk (except for the little bits occupied by the LDM database partition and MS reserved partition).  So I don't think this is an issue as there will be no other partitions that you would want to expose.

Best regards,

	Anton

> Regards,
> Carl-Daniel

-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/