LVM2 headers

LVM2 headers

[DeCay]

Hello!

I came across a rust library (https://crates.io/crates/lvm-sys) which 
depends on lvm2app.h. This header doesn't exist anymore, as far as I was 
able to find.

What's the right way to interact with LVM2 programmatically at the moment ?

Re: LVM2 headers

[Zdenek Kabelac]

Dne 04. 03. 25 v 9:29 DeCay napsal(a):
> Hello!
> 
> I came across a rust library (https://crates.io/crates/lvm-sys) which depends 
> on lvm2app.h. This header doesn't exist anymore, as far as I was able to find.
> 
> What's the right way to interact with LVM2 programmatically at the moment ?
> 

There is either DBus API or just simple good old fashioned  'exec(lvm)' of 
lvm2 command.

We were unable to provide and maintain the C API - as there are simply too 
many restriction which cannot be easily satisfied with any random binary.

So easiest is to simply run lvm2 command or if you are able to consume DBus 
API - you can try to go this path - however than there are many limitations.

Regards

Zdenek

Re: LVM2 headers

[DeCay]

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.

On 3/4/25 6:25 PM, Zdenek Kabelac wrote:
> Dne 04. 03. 25 v 9:29 DeCay napsal(a):
>> Hello!
>>
>> I came across a rust library (https://crates.io/crates/lvm-sys) which 
>> depends on lvm2app.h. This header doesn't exist anymore, as far as I 
>> was able to find.
>>
>> What's the right way to interact with LVM2 programmatically at the 
>> moment ?
>>
>
> There is either DBus API or just simple good old fashioned 'exec(lvm)' 
> of lvm2 command.
>
> We were unable to provide and maintain the C API - as there are simply 
> too many restriction which cannot be easily satisfied with any random 
> binary.
>
> So easiest is to simply run lvm2 command or if you are able to consume 
> DBus API - you can try to go this path - however than there are many 
> limitations.
>
> Regards
>
> Zdenek 

Re: LVM2 headers

[Demi Marie Obenour]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

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.

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: LVM2 headers

[Zdenek Kabelac]

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