feedback sought on mdadm (Debian) sarge->etch upgrade strategy

feedback sought on mdadm (Debian) sarge->etch upgrade strategy

[martin f krafft]

[-- Attachment #1.1: Type: text/plain, Size: 3664 bytes --]

Dear list,

at Marco d'Itri's invitation, I am forwarding the following email,
and a later reply to Marco to you. I would appreciate comments, and
even more if you could keep the pkg-mdadm-devel mailing list on CC!

FYI: mdrun was a hack that would assemble all available arrays, but
it did not honour super-minor numbers, so the devices would have some
random ordering. This is the main reason why I am deprecating it.

---8<---

I am the mdadm maintainer for Debian and faced with the challenge to
ensure upgrades from sarge to etch, given that mdrun is to be
replaced by mdadm.

Since this turns out to be a complicated matter, I have started to
draft my thoughts for a strategy, and I would really welcome any
feedback you may have to offer. It's kinda long and kinda
complicated, but maybe you can find the time... please reply to the
mdadm-pkg-devel mailing list (reply-to set).

  svn cat svn://svn.debian.org/pkg-mdadm/mdadm/trunk/debian/UPGRADE-STRATEGY
  or:
  http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/UPGRADE-STRATEGY?op=file&rev=0&sc=0

---8<---
[abbreviated]

   in the udev README.Debian, you write that md has design errors.
   What exactly do you mean?

   I see a bit of a problem/challenge with mdadm+udev simply because
   when the md module loads, there's no way to know which
   arrays/partitions are actually present. You need to start those
   first.

   The problem is that for udev to find out about the individual
   devices, the arrays have to be started. If mdadm has to start
   them, it needs devices to send ioctl()s. It even needs devices to
   find out whether a device is started.

   This is part of the reason why I thought I'd disable udev
   (without reading README.Debian), because the two were doing 80%
   of the same thing, and 20% different things at times, and I was
   losing oversight of the entire situation, so I thought it would
   be best to eliminate complexity. Of course, it does not work
   because udev is needed to create the device nodes if they are
   started during initrd or kernel load.

   There is a mode of mdadm in which it will simply create the
   device node if it's not there, and it's on by default in sarge
   and etch currently. I think it's a reasonable choice to use this,
   but I have to learn how to control udev properly.

   Again, I need udev for all devices that are not started by mdadm
   during init. But for all devices started by the init script,
   I would like to disable udev. If the device is /dev/mdX, it does
   not actually matter, since udev will just overwrite the node
   created by mdadm with an identical one.

   If, however, mdadm creates a /dev/md/X node, udev will then
   create /dev/mdX, and this confuses the hell out of mdadm later,
   so I really would like to stop udev from creating the node
   /dev/mdX when mdadm creates /dev/md/X. How?

Thanks for your time.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
fitter, healthier, more productive
like a pig, in a cage, on antibiotics
                                                          -- radiohead



----- End forwarded message -----

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
"sobald man über niveau spricht
 ist man längst darüber hinweg."
                                                      -- thomas krafft

[-- Attachment #1.2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: feedback sought on mdadm (Debian) sarge->etch upgrade strategy

[martin f krafft]

[-- Attachment #1.1: Type: text/plain, Size: 2458 bytes --]

also sprach martin f krafft <madduck@madduck.net> [2006.08.14.2253 +0100]:
>    If, however, mdadm creates a /dev/md/X node, udev will then
>    create /dev/mdX, and this confuses the hell out of mdadm later,

To make a long story short, mdadm now knows two superblock versions:
0 and 1. Basically, the source of the problem is that these two use
different algorithms to determine the device name to use. See:

  http://neil.brown.name/git?p=mdadm;a=blob;hb=HEAD;f=super0.c#l228
  http://neil.brown.name/git?p=mdadm;a=blob;hb=HEAD;f=super1.c#l321

The brief_examine_super[01] functions determine the name. While
version-1 superblocks hard-code the name to be used, version-0
superblocks determine it from the super-minor field. They will use
/dev/md/<super-minor> if /dev/md<super-minor> does not exist, and
/dev/md<super-minor> if the device node is already present.

I am not so worried about version-1 right now (even though I don't
like the hardcoding aspect), since all Debian sarge systems have
version-0 superblocks (version-1 was introduced with mdadm 2.5,
sarge has version 1.9). Thus, the systems may use /dev/mdX or
/dev/md/X, and those could be referenced in LVM metadata,
/etc/crypttab, or /etc/fstab (and probably others). Thus, I should
make sure that the array is started and the expected device node
present by the time they are used (by LVM/dm-crypt/whatever).

The "solution" right now is that mdadm creates a /dev/mdX ->
/dev/md/X symlink if the device is assembled as /dev/md/X, and
/dev/mdX otherwise.

Obviously, this is bad because mdadm must thus know about block
device major/minor numbers, which it should not have to. The right
way would IMHO be if mdadm just told the kernel to create a device
e.g. /dev/md6 and assemble the array according to information passed
to it. A preliminary such interface exists, but only *after* the md
devices have been created, otherwise /sys/block/mdX does not exist.

So it's all a big catch-22 and I am not sure how to best handle it.
Thus, I'd be happy to hear your input!

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"arguments are extremely vulgar,
 for everyone in good society
 holds exactly the same opinion."
                                                        -- oscar wilde

[-- Attachment #1.2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel