summaryrefslogtreecommitdiff
path: root/debian/UPGRADE-STRATEGY
blob: 3d1e76373c9ebd0084322d0c2adf5af07f486362 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
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@debian.org>  Mon, 14 Aug 2006 02:41:29 +0100

$Id$