[dm-devel] snapshot of mirror (was: possible regression by the barrier patch in 2.6.30-rc2)

[Mikulas Patocka]

> Anyway, suspend unconditionally purges all I/Os from target drivers. All 
> that this "noflush" flag does is that it allows the I/O to be held and 
> requeued for new dm table incarnation, if the target requests it with 
> DM_MAPIO_REQUEUE (dm-raid1 and dm-multipath do it). If no target returns 
> DM_MAPIO_REQUEUE, then "flush" and "noflush" suspend is equivalent.

Hmm, I think it makes snapshot-of-mirrors implementation impossible.

If we create the first snapshot or delete the last snapshot, we must 
inevitably suspend the underlying origin device. If we do a "flush" 
suspend and mirror log or leg fails at the same time, the i/o would be 
incorrectly returned with -EIO. If we do a "noflush" suspend, we couldn't 
synchronize the filesystem on snapshot creation and we couldn't get the 
I/Os out of origin target (because they would be queued in the underlying 
-real device).

Mirrors must to be self-sufficient (i.e. handle errors on their own 
without queuing i/os and needing immediate action of dmeventd) to enable 
snapshots-of-mirrors work. Jon, will your log duplication work meet this 
requirement?

Mikulas