r109 - mdadm/trunk/debian
madduck at users.alioth.debian.org
madduck at users.alioth.debian.org
Mon Aug 14 01:52:53 UTC 2006
Author: madduck
Date: 2006-08-14 01:52:52 +0000 (Mon, 14 Aug 2006)
New Revision: 109
Added:
mdadm/trunk/debian/UPGRADE-STRATEGY
Log:
adding a document to braindump the upgrade requirements
Added: mdadm/trunk/debian/UPGRADE-STRATEGY
===================================================================
--- mdadm/trunk/debian/UPGRADE-STRATEGY 2006-08-13 22:43:54 UTC (rev 108)
+++ mdadm/trunk/debian/UPGRADE-STRATEGY 2006-08-14 01:52:52 UTC (rev 109)
@@ -0,0 +1,125 @@
+mdadm: upgrading from sarge -- braindump
+========================================
+
+The mdrun deprecation means we have to find a proper way to migrate from
+sarge. The plan is to support
+
+ [a] bringing up all arrays in the initramfs
+ [b] bringing up only selected arrays in the initramfs, the rest by the
+ mdadm-raid init script
+
+We want to be able to deal with:
+
+ - any filesystem on RAID, including root and swap
+ - assembly/starting by kernel, mdadm -A, and mdadm -As (mdrun)
+ - partitionable arrays
+ - plain /dev, udev, or devfs
+
+We explicitly do not support:
+
+ - custom names for device nodes
+
+What do we have to worry about?
+
+ - root must be mounted either by the initrd or by the kernel
+ - other RAIDs must be mounted either by the initrd or by the kernel or by
+ the init script
+ - device nodes must exist by the time the init script finished
+ - no real need to worry about root, but good to have a device node on the
+ running system anyway. See next point.
+ - if an array is brought up by the kernel or initrd, device nodes must be
+ created by init script for each running array.
+ - if an array is to be brought up by the init script, mdadm autocreates
+ the device nodes.
+
+How to determine what to assemble in the initrd?
+
+ - If /etc/mdadm/mdadm.conf or /etc/mdadm.conf are present:
+ - for the case when file is autogenerated, then it helps to dump mdadm -Es
+ output to /var/lib in preinst to have a reference point. We can then
+ hash-compare the relevant parts of the dump with the filesystem copy. If
+ they match, just use the mdadm.conf file.
+ Notable differences between 1.9 and 2.5 output of -Es: 2.5 does not
+ provide the devices= line, otherwise identical.
+ - If no match, compare device name, level, UUID? Is that enough? If those
+ match, just use the mdadm.conf file.
+ - If still no match, abort. Require user to fix mdadm.conf file and
+ touch /var/run/mdadm.conf-okay.
+ - If /var/run/mdadm.conf-okay exists, just use the mdadm.conf file.
+ - Use debconf answer to determine which arrays to start.
+ - if all, just run mdadm -As during initrd with the system mdadm.conf
+ - if specific, just run mdadm -A with the system mdadm.conf
+
+ - If /etc/mdadm/mdadm.conf and /etc/mdadm.conf are absent:
+ - configure initramfs to start all arrays
+ - does it make sense to check super-minor for running arrays? mdrun
+ ignored them, so we are likely to find deviations, but those may spoil
+ the boot. What to do if there are deviations? Configure initrd to update
+ the super minor? This would mean to start ever array explicitly
+ according to mdadm -Es/mdadm -D output from the running system.
+ - If super-minors match, just use mdadm --homehost --auto-update-homehost.
+ - Should we just autocreate (mdadm -Es) an mdadm.conf from the running
+ system in case it's absent and use that?
+ - what does mdadm 1.9.0 do when it examines a version-0 superblock of
+ /dev/mdX, but the super minor is listed as Y?
+ - what does mdadm 2.5.x do in this situation?
+
+Who creates the device nodes, and when?
+
+ - plain /dev
+ - let mdadm create them. If told to start all arrays (mdadm -As
+ --auto=yes), mdadm will create the nodes even for nodes that have
+ already been started. This is a feature we can rely on.
+ - or call makedev during postinst and init script. Will create 32 nodes.
+ - devfs
+ - nodes get created when the module is loaded. ** no partition nodes for
+ partitionable arrays get created **
+ - see above, mdadm would create nodes. For partitionable arrays with 4+
+ partitions, there's a problem, upstream knows; --auto=yes only creates
+ 4 partitions. We cannot pass --auto=p8 (to create 8) because p will only
+ create partitionable array nodes. yes creates 4 of them. Suggestion is
+ to allow e.g yes27 to create nodes based on the name used, and
+ pre-create 27 partitions in this case if it's for a partitionable array.
+ - udev
+ I AM ENTIRELY UNSURE ABOUT THIS YET
+ - in regular, non-devfs mode:
+ - creates /dev/mdX if started as /dev/mdX
+ - creates symlink from /dev/mdX to /dev/md/X if started as /dev/md/X
+ - in devfs mode: TODO
+
+
+IGNORE THIS FOR NOW:
+
+
+ Three letter keys:
+ 1. which filesystems: a=all r=root(+others) o=others
+ 2. assembled by: m=mdadm k=kernel b=both
+ 3. dev style p=plain u=udev s=devfs
+
+ Equivalence classes:
+
+ m k b
+ a ABA EFE IJI
+ r ABA EFE IJI
+ o CDC GHG KLK
+
+ A: root started by mdadm/initrd, others by mdrun; device nodes present
+ B: root started by mdadm/initrd, others by mdrun; device nodes by udev
+ C: others started by mdrun, device nodes present
+ D: others started by mdrun, device nodes by udev
+ E: all started by kernel; device nodes present
+ F: all started by kernel; device nodes by udev
+ G: others started by kernel; device nodes present
+ H: others started by kernel; device nodes by udev
+ I: root started by kernel or mdadm/initrd, some by kernel, others by mdrun
+ device nodes present
+ J: root started by kernel or mdadm/initrd, some by kernel, others by mdrun
+ device nodes by udev
+ K: some started by kernel, others by mdrun, device nodes present
+ L: some started by kernel, others by mdrun, device nodes by udev
+
+
+
+ -- martin f. krafft <madduck at debian.org> Mon, 14 Aug 2006 02:41:29 +0100
+
+$Id: README.recipes 89 2006-08-08 09:33:05Z madduck $
More information about the pkg-mdadm-commits
mailing list