Re: Exporting which partitions to md-configure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 05, 2006, at 20:46, Neil Brown wrote:
On Monday January 30, [email protected] wrote:
Well, if we're going to have a generic facility it should make sense across the board. If all we're doing is supporting legacy usage we might as well export a flag.

I guess we could have a single entry with a string of the form "efi:e6d6d379-f507-44c2-a23c-238f2a3df928" or "msdos:fd" etc -- it really doesn't make any difference to me, but it seems cleaner to have two pieces of data in two different sysfs entries.

What constitutes 'a piece of data'?  A bit? a byte?

I would say that
   msdos:fd
is one piece of data. The 'fd' is useless without the 'msdos'. The 'msdos' is, I guess, not completely useless with the fd. I would lean towards the composite, but I wouldn't fight a separation.

I think this boundary is blurred by the fact that several partition tables allow mostly-arbitrary partition type strings. It would be convenient to not have to worry about the prefix in that case. You would need just the partition type in the parent device anyways, so why munge it into the partition label too?

And if other partition styles wanted to add support for raid auto
detect, tell them "no". It is perfectly possible and even preferable
to live without autodetect.   We should support legacy usage (those
above) but should discourage any new usage.

Why is that, keeping in mind this will all be done in userspace?

partition-type based autodetect is easily fooled. If you take a pair of drives from a failed computer, plug them into a similar computer for data recovery, and boot: you might have two different pairs of drives that both want to be 'md0'. Which wins?

Nonono, not _just_ partition-type based autodetect, but a more complicated solution done _completely_ in userspace. Essentially, by exporting this data you would merely be providing _extra_ pieces of data that could be verified on boot. If I know that my boot RAID volumes for my desktop always have a partition table type string of "Linux_RAID_<unique-id>", then I can _also_ verify that in my initramdisk. This isn't as useful on x86, but that's no reason to prevent it from being used on archs that do allow 31+ character strings for partition types.

I believe there needs to be a clear, non ambigous, causality path from the kernel paramters, initramfs, or machine hardware that leads to the arrays to be assembled and hence the filesystem to be mounted.

This is one way of doing that on a systems with mac partition tables. The autoprobing is mostly useless on x86 hardware due to the limited range of partition types, but that's x86's problem.

Cheers,
Kyle Moffett

--
If you don't believe that a case based on [nothing] could potentially drag on in court for _years_, then you have no business playing with the legal system at all.
  -- Rob Landley



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux