Re: lvm2 deadlock

[Zdenek Kabelac <zdenek.kabelac@gmail.com>]

Dne 07. 06. 24 v 11:03 Jaco Kroon napsal(a):
> Hi,
> 
> On 2024/06/07 00:17, Zdenek Kabelac wrote:
>> Dne 07. 06. 24 v 0:14 Zdenek Kabelac napsal(a):
>>> Dne 05. 06. 24 v 10:59 Jaco Kroon napsal(a):
>>>> Hi,
>>>
>> 
> I'm guessing your "simple way" is workable for the generic case as well, 
> towards that end, is a relatively simple change to the lvm2 tools not perhaps 
> to add an syncfs() call to lvcreate *just prior* to freezing? The hard part is 
> probably to figure out if the LV is mounted somewhere, and if it is, to open() 
> that path in order to have a file-descriptor to pass to syncfs()?  Obviously 
> if the LV isn't mounted none of this is a concern and we can just proceed.
>


Hi

There is no simple answer here -

a) 'sync' flushes all io for all disk in the system - user can play with tools 
like hdparm -F /dev/xxxx  - so still everything in range of 'admin's hand'...

b) it's about the definition of the 'snapshot' moment - do you want to take 
snapshot as of 'now'  or after possibly X minutes where everything has been 
flushed and meanwhile new data flown-in ??

c) lvm2 needs some 'multi LV' atomic snapshot support...

d) with thin-pool and out-of-space potential it gets more tricky....


> What would be more interesting is if cluster-lvm is in play and the origin LV 
> is active/open on an alternative node?  But that's well beyond the scope of 
> our requirements (for now).

Clearly in the cluster case user can use multi-node active LV only in the case 
there is something that is able to 'manage' this storage - i.g. gfs2.   Surely 
use of ext4/xfs this way is out of question...

Regards

Zdenek