Bug#611632: Bug#610421: mdadm: mdadm-raid init-script should depend on hostname

[Mario 'BitKoenig' Holbe]

Not that I like to be nit-picking, but...

On Mon, Jan 31, 2011 at 05:39:35PM +0100, martin f krafft wrote:
> also sprach Mario 'BitKoenig' Holbe <Mario.Holbe at TU-Ilmenau.DE> [2011.01.31.1636 +0100]:
> > How can halt, kexec or reboot? ;)
> All of these get loaded to RAM before init(8) starts the shutdown
> process.

Are you sure about this? How? Where? When?
How does this supposed process make sure the respective pages are not
thrown away without staying alive itself?
And how does it make sure the path to the binaries (I don't know any
other way to execute a binary, even if it already sticks to RAM) is
still reachable with the filesystem having cleaned all its in-ram
structures?

No - the current shutdown process does really rely on the rootfs being
available until the very last binary is exec()uted.

> > Of course you know umountroot doesn't (yet) really umount the root
> > filesystem.
> Fact is that it's not possible to stop all RAID arrays (see the FAQ)
> while they are being used, even by a read-only rootfs, unless ???

Yes. Currently. That's why I did note 1.

> > 1. md once allowing setting read-only when the upper layer
> > restricts itself to read-only.
> at least for mdadm, the kernel synchronises the superblocks just
> before reboot, so that the shutdown process is ugly, but no data is
> endangered.

Yes. That's why I didn't raise the bug's severity.

However, there are enough mails out there on enough mailinglists
reporting ever-fscking filesystems with underlying md or/and(?) more
complex stackings involved, hence I believe the (small) effort to move
mdadm-raid always close to umountroot is justified.
I don't really argue for scheduling it *after* umountroot - and by no
means immediately. That was just a minor side-note in my patch-mail.


Mario
-- 
Selbst im Hirn des weisesten Mannes gibt es einen toerichten Winkel.
                                                      -- Aristoteles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20110131/5cb8c94f/attachment.pgp>