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
