Bug#415441: uswsusp: fails to resume if initrd starts raid arrays

Tim Dijkstra tim at famdijkstra.org
Mon Mar 19 21:34:14 UTC 2007


[ I'm adding the mdadm maitainer to the CC-list, maybe he has some
useful comments. ]

On Mon, 19 Mar 2007 09:58:43 -0600
Luis Rodrigo Gallardo Cruz <rodrigo at nul-unu.com> wrote:

> Package: uswsusp
> Version: 0.6~cvs20070202-1
> Severity: important
> 
> s2disk does not mark (software) raid arrays as clean when shutting
> down the machine.

I'm not to familiar with software raid, but this sounds like the way it
should be. I guess this is similar to the state a journaling filesystem
can be in during suspend; Part of the state is still in memory, part is 
on disk.

Maybe the mdadm people can tell if it is possible to leave a raid array
in a `clean state' during resume. I would guess that means stopping the
whole array, wouldn't it? That is of course out of the question...

> On the next bootup, the mdadm support in the initrd starts up the arrays 
> and, finding them dirty, starts a background reconstruction. 
> When, afterwards, uswsusp tries to resume, after properly finding and
> loading the resume image, 

I think this is the problem, we should start resume, before the raid
array is up. ( This would probably mean you can't have your swap on a
raid array ... not sure )

Anyway, this will get us in an ordering problem: we do want to allow
things like swap on lvm or crypt-partitions, this means I want to 
start resume after they have been setup, e.g. after local-top. But 
then also the mdadm hook has been run.

A solution would be to have the raid 'discovery' phase in local-top
so we know what partitions are on it, but split of the start of the
reconstruction phase to anther hook in local-bottom, just like mounting
filesystems is done after premount. Because reconstruction is done in
the background, I presume it can wait for a little while before it is
started.

What do the mdadm maintainers think? Is this doable?


grts Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20070319/1f3554b2/signature.pgp


More information about the pkg-mdadm-devel mailing list