Re: lvm2 deadlock

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

Dne 07. 06. 24 v 0:14 Zdenek Kabelac napsal(a):
> Dne 05. 06. 24 v 10:59 Jaco Kroon napsal(a):
>> Hi,
>>
>> On 2024/06/04 18:07, Zdenek Kabelac wrote:
>>> Dne 04. 06. 24 v 13:52 Jaco Kroon napsal(a):
>>> Last but not least -  disk scheduling policies also do have impact - to 
>>> i.e. ensure better fairness - at the prices of lower throughput...
>> We normally use mq-deadline, in this setup I notice this has been updated to 
>> "none", the plan was to revert, this was done in collaboration with a 
>> discussion with Bart van Assche.  Happy to revert this to be honest. 
>> https://lore.kernel.org/all/07d8b189-9379-560b-3291-3feb66d98e5c@acm.org/ 
>> relates.
> 
> Hi
> 
> So I guess we can tell the store like this -
> 
> When you've created your 'snapshot' of a thin-volume - this enforces full 
> flush (& fsfreeze) of a thin volume - so any dirty pages need to written in 
> thin pool before snapshot could be taken (and thin pool should not run out of 
> space) - this CAN potentially hold your system running for a long time 
> (depending on performance of your storage) and may cause various lock-ups 
> states of your system if you are using this 'snapshoted' volume for anything 
> else - as the volume is suspended - so it blocks further operations on this 
> device  - eventually causing full system circular deadlock  (catch 22) - this 
> is hard to analyze without whole picture of the system.
> 
> We may eventually think whether we can somehow minimize the amount of holding
> vglock and suspending with flush & fsfreeze -  but it's about some future 
> possible enhancement and flush disk upfront to minimize dirty size.

I've forget to mention that a 'simplest' way is just to run  'sync' before 
running 'lvcreate -s...' command...

Regards

Zdenek