[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Advanced Startup/Shutdown with multilayered block-devices



Hi.

IIRC, I've already posted this here some time ago...
A few days ago now, I've submitted #616729, suggesting Martin, that one
could possible improve mdadm's initramfs-hooks to only include something
in the initramfs, if really needed.

That turned out to become a more general discussion between him and
myself, again about the ideas of what I've once called "advanced
Startup/Shutdown with multilayered block-devices".

In his last reply he suggest me, that we should move discussion back to
d-d... so here I am.


I've once wrote a wiki article down, where I've started to collect some
ideas:
http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices

Might also be worth to read the #616729, mentioned above.


The basic idea is, to make startup/shutdown, with or without initramfs,
powerful enough, to handle all kinds of block devices hierarchies that
should be set up.
Most important of course, in order to mount filesystems, and most
important there, in order to mount the root-fs and to make resume
devices available in order to boot.

And the same for shutdown, all blockdevs should be (in their order)
cleanly be stopped/removed/etc.
This doesn't only safe us from data corruption (just imaging that the
block level barriers in the kernel don't work as expected), but also can
have security implications (e.g. dm-crypt being used for the root-fs).


It's quite clear, that a real generic solution could be very
complicated, it might not be possible to implement it dynamically (e.g.
auto-find everything) but static rules in the (e.g.) initramfs might be
required (actually most likely).
It may also require an event based boot-system.
Worst, it would require to get all the affected maintainers on board,
which does not only mean the maintainers of block-device-tools (lvm2,
dmsetup, mdadm, cryptsetup, ndb, loop-devices, multipath-tools , etc.
etc.) but also the booting-guys (sysvinit, initscripts, ....)


Well, I'm curious to see whether other people find it worth, to
implement "all this".


Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Reply to: