[lvm-devel] Re: Deactivating volume with mounted snapshot

[Mikulas Patocka]

On Thu, 15 May 2008, Alasdair G Kergon wrote:

> On Wed, May 14, 2008 at 07:30:17PM -0400, Mikulas Patocka wrote:
>> With merging, it will cause corruption --- if one snapshot is merging and
>> you don't have all the other snapshots loaded, the non-active snapshots
>> won't be updated as the merging goes on. So they'll be corrupted.
>
> If that can happen it suggests the detailed set of activation steps needs
> further refining and is not correct yet.

I think I have it already correct. The patch that corrects it is 
http://lacrosse.redhat.com/~mpatocka/patches/kernel/dm-snapshot-remove-active-variable.patch

Basically, lvm suspends all the devices, then loads the dm table for all 
of them and then resumes them.

I start merging at preresume method. When I start merging, all the other 
snapshots are already loaded in the table and can allocate new exceptions. 
The patch changes it so that they can accept new exceptions always.

>> Currently the contstraint is "if the device is open, you can't deactivate
>> it". I'd like change it to "if the device is open or some of its snapshots
>> are open, you can't deactivate it".
>
> Catch-22 then.  Which do you deactivate first?  We cannot handle that
> at kernel level with the current interface.

You are right. The possible solutions:

* block opening of suspended device until the device is resumed (or 
deleted) --- easiest, but most scary. Theoretically it should be OK --- 
you already should not open a file while there is something suspended (the 
memory-allocation deadlock) --- but it may make some of these deadlocks 
very visible. Maybe making the deadlocks visible is a good thing, it's 
much easier to solve reproducible deadlock than nonreproducible.

* undo the deactivation if one of the devices can't be removed because it 
is open --- probably the hardest.

* replace the open device's table with error target --- if it has 
journaled filesystem, it will recover fine. And it won't damage other 
snapshots.

* let it be, hoping that admin won't simultaneously open and deactivate a 
device :-/

> But by all means add that extra protection to the userspace code.
> The userspace code should not assume it happened though.
>
>> Even without merging, the current approach is not perfect, as you will end
>> up with a device that you can't deactivate (the origin is deactivated, the
>> snapshot is active; lvchange -an on the snapshot will return error;
>> lvchange -an on the origin will see that it is already inactive and do
>> nothing)
>
> That can be fixed: lvchange -an on the origin should complete the process.
> (It probably used to do that before some optimisation got added.)
>
> Alasdair
> -- 
> agk at redhat.com

BTW. Tomorrow I'm going to Brno to medical exam at Red Hat on Thursday and 
meeting on Friday, so I won't be on IRC and email much.

Mikulas