Re: dm: bind new table before destroying old

[Mike Snitzer <snitzer@redhat.com>]

On Tue, Nov 10 2009 at  8:16pm -0500,
Alasdair G Kergon <agk@redhat.com> wrote:

> Questions:
> 
>   Do all the targets correctly flush or push back everything during a
>   suspend (including workqueues)?
> 
>   Do all the targets correctly sync to disk all internal state that
>   needs to be preserved during a suspend?
> 
> In other words, in the case of an already-suspended target, the target
> 'dtr' functions should only be freeing memory and other resources and
> not causing I/O to any of the table's devices.
> 
> All targets are supposed to be behave this way already, but please
> would you check the targets with which you are familiar anyway?
> 
> Alasdair
> 
> 
> From: Alasdair G Kergon <agk@redhat.com>
> 
> When replacing a mapped device's table during a 'resume', delay the
> destruction of the old table until the new one is successfully in place.
> 
> This will make it easier for a later patch to transfer internal state
> information from the old table to the new one (something we do not currently
> support) while giving us more options for reversion if a later part
> of the operation fails.

I have confirmed that this patch allows handover to work within a single
device.

The error recovery, will it be done unilaterally in the DM core (on
preresume failure)?  Or will each target driver need to call a DM core
callback if it'd like recovery?

Mike