also sprach Ratiu Petru <petre@lsd.ro> [2006.11.09.0634 +0100]:
> I noticed that recent mdadm packages require the presence of
> mdadm.conf, at least for the boot process.
This was a necessary step because the magic in use by mdadm
(specifically mdrun) previously was unpredictable in many cases:
http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file&rev=0&sc=0
Thus, in the interest of better control, I chose not to make use of
the magic during every boot anymore, but only once during the
creation of the mdadm.conf file.
I've tried to make the change as harmless as possible, but I could
not conscientiously make the process transparent because there were
too many free factors involved and thus too many potential points of
failure.
Users of apt-listchanges will have seen the NEWS announcement when
upgrading:
http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/NEWS?op=file&rev=0&sc=0
I suggest people who don't have apt-listchanges installed yet to do
so and to active the display and mailing of at least NEWS entries.
> * Changing order of drives
> Especially with SATA drives, it's very easy to lose the connection order
> so I made great use of the drive order detection, helped by a smart
> bootloader that uses whatever drive is first for all operations, of course
> with root raid1. Will the drive order change conflict with the order from
> mdadm.conf?
I am not sure what you mean.
However, the suggested way to use mdadm.conf is through the
specification of UUIDs. If you inspect the output of
/usr/share/mdadm/mkconf, you'll notice that there is no devices=
parameter anymore.
Thus, the file really links UUIDs to md device nodes (e.g. /dev/md0)
and the boot process ensures that all md components with the given
UUID in the superblock will be assembled to become /dev/md0 during
ever boot. It does not matter whether they change names from
/dev/hda to /dev/sdc or /dev/hdb4 to /dev/hdd1. Especially in the
light of the impending libata transition for PATA arrays (when
/dev/hd* becomes /dev/sd*), this is a very nice feature which will
prevent many a headache.
> * Arrays with missing members
> When converting from non-raid boot to raid boot, i would create arrays
> with missing members instead of the active partitions, copy everything to
> the array, reboot to raid, complete the array, synchronize, profit! I'm
> not sure at what steps i will have to rebuild mdadm.conf and initrd.
The automatic rebuilding should take care of this:
dpkg-reconfigure linux-image-$(uname -r)
since mdadm.conf does not list the components anymore, you don't
need to change it after you complete the array.
If you create /dev/md1 as a degraded three-disk RAID5 array with
/dev/sd[ab]1 as components, these two will have the same UUID in
their superblocks, and mdadm.conf will link /dev/md1 to this UUID.
If you now reboot, mdadm only finds two components with the UUID of
/dev/md1, but since it *can* assemble a three-disk RAID5 with only
two disks, it will do so.
Now you can add /dev/sdc1 to the array (mdadm --add /dev/md1
/dev/sdc1), which will copy the existing UUID to /dev/sdc1's
superblock. If you then reboot, mdadm finds all three components and
assembles /dev/md1. No need to change mdadm.conf
> * Recover from live CD
> I often found myself booting with Knoppix, modprobing md and raid*, doing
> a mdrun, creating the md devices (although i hear udev should do it from
> now on),
No, udev does not do it yet. Unless you have specified the auto=
option on the CREATE line in mdadm.conf, you can tell mdadm to
create the devices for you by specifying --auto=yes on the command
line. See mdadm(8) section DEVICE NAMES for the special cases.
> mounting the arrays and doing the recovery. Will this be possible
> anymore without having a prepared mdadm.conf? More importantly, will the
> RAID superblocks be compatible with older or newer mdadm binaries or
> kernel modules?
Yes, they will be compatible.
And yes, you can do without mdadm.conf because you can trivially
create one after you booted Knoppix. Instead of mdrun (which will be
removed after etch has been released), just execute the following
commands:
modprobe md
echo DEVICE partitions > /etc/mdadm.conf
mdadm -Es >> /etc/mdadm.conf
mdadm -As --auto=yes
I know this is more effort than before, but the magic of mdrun was
really not acceptable anymore.
Once Knoppix adopts a newer mdadm package, you'll be able to do:
modprobe md
/usr/share/mdadm/mkconf generate
/etc/init.d/mdadm-raid start
I'll provide a helper script /usr/share/mdadm/startall which does
the above in version 2.5.6-2 of the package. However, this may have
to wait until after etch as I am not sure I'll get 2.5.6 into etch.
It's this script though:
http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/startall?op=file&rev=0&sc=0
I'd appreciate if people tested it:
http://blog.madduck.net/debian/2006.10.23_testing-mdadm
(2.5.6-2 will be available in a few minutes)
This is what it looks like, under Knoppix, following a fresh boot.
root@0[~]# /usr/share/mdadm/startall
Assembling MD array md1...done (started [2/2]).
Assembling MD array md2...done (started [2/2]).
Assembling MD array md3...done (started [3/3]).
Assembling MD array md4...done (degraded [1/2]).
Generating udev events for MD arrays...done.
Also see http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.mdrun?op=file&rev=0&sc=0
> Also, at this time the only way I'm confident of rebuilding
> mdadm.conf is by dpkg-reconfigure mdadm. Is there some sort of
> update-mdadm script to do this?
'/usr/share/mdadm/mkconf prints to stdout
'/usr/share/mdadm/mkconf generate' creates mdadm.conf, unless it already exists
'/usr/share/mdadm/mkconf force-generate' -- well, you know.
But I doubt you need it. mdadm should create an mdadm.conf upon
upgrade on systems that don't have one, and it can use existing
ones, but only if the admin permits it to do so. Again, see
http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file&rev=0&sc=0
for the rationale.
> Sorry for the lengthy mail, but I couldn't get enough info from
> the packages' documentation in order to predict how such scnarios
> will be affected in the future.
/me scratches head. Maybe you could give me specific infos at what's
missing in the docs? After all, mdadm now comes with 1000 lines of
documentation which have not been in sarge...
http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/?rev=0&sc=0
Cheers,
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"si tu veux construire un bateau, il ne faut pas réunir des hommes
pour aller chercher le bois et les outils et les préparer à se
répartir les différents travaux. Il faut plutôt leur donner l'envie,
la passion de la mer infinie."
-- antoine de saint-exupéry
Attachment:
signature.asc
Description: Digital signature (GPG/PGP)