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

[martin f krafft]

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 at 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 at madduck
 
spamtraps: madduck.bogus at madduck.net
 
"sobald man über niveau spricht
 ist man längst darüber hinweg."
                                                      -- thomas krafft
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (GPG/PGP)
Url : http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20060814/f1e7ad5e/attachment.pgp