r188 - mdadm/trunk/debian
madduck at users.alioth.debian.org
madduck at users.alioth.debian.org
Sat Sep 23 10:44:58 UTC 2006
Author: madduck
Date: 2006-09-23 10:44:58 +0000 (Sat, 23 Sep 2006)
New Revision: 188
Removed:
mdadm/trunk/debian/UPGRADE-STRATEGY
Log:
no need for this doc anymore
Deleted: mdadm/trunk/debian/UPGRADE-STRATEGY
===================================================================
--- mdadm/trunk/debian/UPGRADE-STRATEGY 2006-09-23 10:35:49 UTC (rev 187)
+++ mdadm/trunk/debian/UPGRADE-STRATEGY 2006-09-23 10:44:58 UTC (rev 188)
@@ -1,127 +0,0 @@
-mdadm: upgrading from sarge -- braindump
-========================================
-
-THIS IS AN OBSOLETE DOCUMENT
-
-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 MD, 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 MD arrays 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$
More information about the pkg-mdadm-commits
mailing list