4 releases (2 breaking)
0.3.1 | Mar 5, 2019 |
---|---|
0.3.0 | Oct 15, 2018 |
0.2.0 | Oct 15, 2018 |
0.1.0 | Oct 2, 2018 |
#22 in #physical
36KB
854 lines
lvm
safe rust lvm bindings
lib.rs
:
Taken from the lvm2app.h header file: The API is designed around the following basic LVM objects:
- Physical Volume (pv_t) 2) Volume Group (vg_t) 3) Logical Volume (lv_t).
The library provides functions to list the objects in a system, get and set object properties (such as names, UUIDs, and sizes), as well as create/remove objects and perform more complex operations and transformations. Each object instance is represented by a handle, and handles are passed to and from the functions to perform the operations.
A central object in the library is the Volume Group, represented by the VG handle, vg_t. Performing an operation on a PV or LV object first requires obtaining a VG handle. Once the vg_t has been obtained, it can be used to enumerate the pv_t and lv_t objects within that vg_t. Attributes of these objects can then be queried or changed.
A volume group handle may be obtained with read or write permission. Any attempt to change a property of a pv_t, vg_t, or lv_t without obtaining write permission on the vg_t will fail with EPERM.
An application first opening a VG read-only, then later wanting to change a property of an object must first close the VG and re-open with write permission. Currently liblvm provides no mechanism to determine whether the VG has changed on-disk in between these operations - this is the application's responsiblity. One way the application can ensure the VG has not changed is to save the "vg_seqno" field after opening the VG with READ permission. If the application later needs to modify the VG, it can close the VG and re-open with WRITE permission. It should then check whether the original "vg_seqno" obtained with READ permission matches the new one obtained with WRITE permission.
Dependencies
~0.3–2.7MB
~50K SLoC