Bug#552130: A *boot* order problem...

[Bjørn Mork]

martin f krafft <madduck at debian.org> writes:

> Where is the write-intent bitmap stored? /lib/init/rw is available
> r/w even before checkroot. I'd rather not move mdadm-raid around
> because it took months to settle on the current position. So
> instead, we should make sure that mdadm knows where to try to drop
> its files.

I understand that you don't want to mess up the ordering. Although it
solved the problem for me, that's just my simple test system.

I initially stored the write-intent bitmap on the root file system
because that was the earliest available file system as far as I knew.
Moving it somewhere else is of course an option, and it would probably
be a good thing if mdadm helped us users standardize both location and
file name.  

But I don't see how /lib/init/rw can be used, as that is usually a ramfs
on Debian:

bjorn at canardo:~$ df /lib/init/rw
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  4100148         0   4100148   0% /lib/init/rw
bjorn at canardo:~$ ls -la /lib/init/rw
total 4
drwxr-xr-x 4 root root  100 2010-01-16 12:03 .
drwxr-xr-x 3 root root 4096 2008-08-24 22:16 ..
drwxr-xr-x 2 root root  100 2010-01-16 12:03 .mdadm
-rw-r--r-- 1 root root    0 2010-01-16 12:03 .ramfs
drwxr-xr-x 2 root root   60 2010-01-16 12:04 sendsigs.omit.d


Writeable is not enough, it has to be persistent too.  The bitmap will
have to survive a crash (e.g. sudden power failure) to be useful.

One could maybe imagine copying the bitmap from a readonly rootfs to
/lib/init/rw on boot and start the array with it there, then moving the
bitmap back to the rootfs (using mdadm --grow) later when the root is
writeable?  But this would just add unnecessary complexity.  It would
require some "mdadm-raid-late" initscript anyway, and you could just as
well add one handling only arrays with external write intent bitmaps.

Anyway, some check should probably go into the current mdadm initscripts
(both /usr/share/initramfs-tools/scripts/local-top/mdadm and
/etc/init.d/mdadm-raid) to avoid them starting an array with an external
bitmap if the bitmap is unwriteable, as it really is better to start it
manually later than losing the bitmap.  Unless the array contains a
critical filesystem, of course, in which case I don't think an external
bitmap can be used.

Phew, I'm starting to see some of the ordering problems you are facing,
and I guess this is only the top of the iceberg...  I have a lot of
respect for the job you are doing sorting this out.  Thanks.



Bjørn