Re: [[Patch mdadm] 2/5] Move the files mdmon opens into /dev/ to support handoff after pivotroot

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

 



On Thu, Feb 4, 2010 at 11:45 AM, Doug Ledford <dledford@xxxxxxxxxx> wrote:
> To be fair, if post-hoc versus initial made any difference what so ever,
> then so would the fact that I wouldn't have chosen to have these files
> exist at all.  I would have made incremental assembly work without a map
> file and I would have made imsm superblock handling be in the kernel.
> So, I'm dealing with the consequences of decisions I didn't make and
> wouldn't have made.  I don't think it's then fair to put some sort of
> 'premeditated' versus 'dealing with the situation' bias on my response.

On the argument about where to place the mdmon files I am now torn
between the "Neil" and "Doug" positions, but on the decision of where
to place imsm superblock handling I stand behind the design decision
to put it in userspace.

1/ If you take a look at native md superblock support you see that the
support code is duplicated between kernel-space and user space, having
it all handled in userspace means only one code base to maintain
(elegant aspect #1).

2/ The kernel can simply worry about the *mechanism* of providing raid
while all the assembly *policy* and support for any number of
superblock formats is relegated to where policy belongs (elegant
aspect #2).

2a/ This simply follows in the path of the design decision to not
support in-kernel auto-assembly of version-1 superblocks which started
the requirement to use an initramfs to boot software raid.  (this is a
not so elegant aspect because it mandates an initramfs to boot, but I
don't think a general purpose distro can ever get away from that
requirement).

I will say that needing to touch several software packages (kernel,
initramfs, initscripts, mdadm) to get imsm superblock support has
added some excitement to the process in the short term.  Long term I
think the elegant aspects of the decision will prove their worth.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux