Re: LVM2 headers

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

Dne 05. 03. 25 v 0:48 Demi Marie Obenour napsal(a):
> On Tue, Mar 04, 2025 at 09:13:54PM +0400, DeCay wrote:
>> Interesting, thank you for your answer! Yes, DBus should work for my
>> use-case.
>>
>> At the same time, I'm looking into lvm2cmd.h right now, but it seems to be
>> designed for the CLI `lvm` you mentioned.
> 
> LVM2 can't be embedded in an application because there are points where
> if LVM crashes, the whole system must be rebooted.  Furthermore, there
> are points where accessing memory that is not mlock'd might hang
> forever.

Yep it's around this logic where lvm2 needs to lock itself into memory
whenever it needs to suspend devices - as this may suspend access to
swap device if such device would be living on currently suspended LV.

There could be possibly some mode where user is 'promising', he is not
using lvm2 on devices he using to run his system - in this case  the
rules might be way more relaxed - but explain all this to all users is 
probably too complex...

> If you plan to frequently perform LVM operations, then LVM is probably
> the wrong tool for the job.  LVM operations often take 0.3 seconds or
> more and are highly disruptive to other I/O on the system.

We are continuously making lvm2 faster but clearly if there is a suspend 
operation that requires to flush all disk IO operation - that may cause a 
significant 'sleep' delay.

On the other hand - if the user does require much higher responsiveness of 
such lvm2 commands - he then needs to significantly reduce  'dirty-page-cache' 
size used by his system - so there are no long flushing delays.

If there are seen more delays for other reason unrelated to suspend IO wait,
I'd like to see them with timed example whether we can run them faster.


Regards

Zdenek