| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This headers were not resolving anything used for compiled .c files.
Remove unused util.c file.
|
| |
|
|
|
|
|
|
|
| |
monitoring state of the logical volumes they are currently acting on.
Until now, every time a logical volume has been changed by a dmeventd plugin,
this plugin would have called back to dmeventd through the external FIFO
mechanism. I am fairly sure this was superfluous, inefficient and possibly even
dangerous.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new implementation of locking function instead
of mlockall() that may lock way too much memory (>100MB).
New function instead uses mlock() system call and selectively locks
memory areas from /proc/self/maps trying to avoid locking areas
unused during lock-ed state.
Patch also adds struct cmd_context to all memlock() calls to have
access to configuration.
For backward compatibility functionality of mlockall()
is preserved with "activation/use_mlockall" flag.
As a simple check, locking and unlocking counts the amount of memory
and compares whether values are matching.
|
| | |
|
| |
|
|
| |
was preventing device scans in lvconvert --repair running from inside dmeventd.
|
| |
|
|
| |
Split LVM_VERSION into MAJOR, MINOR, PATCHLEVEL, RELEASE and RELEASE_DATE.
|
| |
|
|
|
|
|
|
| |
Very simple / crude method of removing 'is_static' from initialization.
Why should we require an application tell us whether it is linked
statically or dynamically to libLVM? If the application is linked
statically, but libraries exist and dlopen() calls succeed, why
do we care if it's statically linked?
|
| |
|
|
|
| |
* tools/lvmcmdlib.c: Initialize "ret". Also avoid useless string
comparison.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
