[linux-lvm] Resend: API for retrieving linux lvm information

Stanley Yue stanley.yue at gmail.com
Wed Sep 8 01:39:24 UTC 2004


Alasdair:

Thanks for your response.

Given your last comment, I think i'm going to just perform the parsing
from cmd-line or through /proc/lvm instead if using the apis.

As far as the parsing goes, is it better (in terms of compatibility,
output stability) to parse against the command line output (i.e.
lvdisplay) or against the /proc/filesystems (i.e.
/proc/lvm/VGs/vg00/LVs)?

Also, it is unclear to me what is the meaning of each fields/values by
looking at the information stored in the /proc/* by itself.

[root at DAP-RHLNX1 LVs]# cat /proc/lvm/VGs/vg00/LVs/vol1 
name:         /dev/vg00/vol1
size:         409600
access:       3
status:       1
number:       0
open:         0
allocation:   0
device:       58:00

For example, what does it mean by "access: 3"?

Is all the information available from query apis (i.e. pvdisplay,
lvdisplay) also available from the /proc/lvm subdirectories?
How can we find out the meaning of each fields/value from the
/proc/lvm information?

Thanks,

Stanley


On Tue, 7 Sep 2004 10:44:13 +0100, Alasdair G Kergon <agk at redhat.com> wrote:
> These answers are for LVM2.
> 
> On Mon, Sep 06, 2004 at 11:04:09PM -0700, Stanley Yue wrote:
> > 1) Is there any api library for retrieve linux lvm configuration? I.e.
> > querying for all the vg(s), pv(s), lv(s) on the system?
>  
> The commands: lvs, pvs, vgs with numerous cmdline flags.
> See lib/report/columns.h for field names
> 
> Access to cmds via library interface: configure --enable-cmdlib
> 
> include lvm2cmd.h
> 
> Example usage: doc/example_cmdlib.c
> 
> Recommend only manipulating one thing at once, so if it
> returns an error you don't have to work out which thing
> went wrong.
> 
> [May yet add an optional argc/argv-style entry point.]
> 
> > 2) If yes, what license is the library release under?
> The library API is intended to be LGPL.
> It's effectively a wrapper around the command-line interface,
> but more efficient because it's able to cache some internal
> state between commands.
> [I shall correct the copyright notices: the library entry-point
> got moved which messed up the original GPL/LGPL code split.]
> 
> liblvm.a does *not* provide a supported API and will sometimes
> change in subtle or incompatible ways without warning.  Don't be
> tempted to link against it.  The only interface supported
> is the one based on the command-line.
> 
> Alasdair
> --
> agk at redhat.com
>



More information about the linux-lvm mailing list