IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
After some refactorings, we can now move the bulk of _lvcreate into the
internal library, and we can call from liblvm. In the future, we should
refactor lv_create_single further, probably by segtype, to reduce the
size of struct lvcreate_params. For now this is a reasonable refactor
and allows us to re-use the function from liblvm.
Author: Dave Wysochanski <dwysocha@redhat.com>
The main _lvcreate function should deal with extents - the 'size' parameter
is just an intermediate step.
Should be no functional change.
Author: Dave Wysochanski <dwysocha@redhat.com>
Create a new structure, lvcreate_cmdline_params, to store parameters only
relevant for the cmdline, not the library call to lvcreate.
Should be no functional change.
Author: Dave Wysochanski <dwysocha@redhat.com>
Move extents calculation adjustments into their own local functions
right after we read the vg. This calculation really is not part of
the LV create function but is rather an adjustment to the parameters
based on what is given on the cmdline. So we move it outside the main
_lvcreate.
Should be no functional change.
Author: Dave Wysochanski <dwysocha@redhat.com>
A couple simple refactorings of _lvcreate - should be no functional change.
Move tags_ARG parsing into _lvcreate_params. Also use lp->voriginsize
instread of arg_count(). These refactorings make it easier to move the
bulk of _lvcreate into the library.
Author: Dave Wysochanski <dwysocha@redhat.com>
Although the tools do not currently do this, we update lvm_vg_extend
to do an implicit pvcreate on an uninitialized device. The tools will
soon be refactored to do this as well, but more work is needed in the
tools. For now we update lvm_vg_extend since this is the behavior
required by liblvm.
With this change, the simple liblvm unit test, test/api/vgtest.c
should pass whether or not the device is initialized.
Author: Dave Wysochanski <dwysocha@redhat.com>
The implicit pvcreate require either moving the ORPHAN_VG lock outside
pvcreate_single or somehow having the function know or detect whether
the ORPHAN_VG lock is already held.
Author: Dave Wysochanski <dwysocha@redhat.com>
Passing NULL for pvcreate parameters gives you default parameters for
pvcreate_single.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Author: Dave Wysochanski <dwysocha@redhat.com>
In preparation for implicit pvcreate during vgcreate / vgextend,
move bulk of pvcreate logic inside library.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Author: Dave Wysochanski <dwysocha@redhat.com>
We must hold the VG_ORPHAN lock until we commit to disk. Otherwise,
we risk a race condition on vgcreate / vgextend. Reverts the following
commit:
commit 72a41480ba
Author: Dave Wysochanski <dwysocha@redhat.com>
Date: Fri Jul 10 20:09:21 2009 +0000
Move orphan lock obtain/release inside vg_extend().
With this change we now have vgcreate/vgextend liblvm functions.
Note that this changes the lock order of the following functions as the
orphan lock is now obtained first. With our policy of non-blocking
second locks, this should not be a problem.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
The lvm_list_vg_{names|ids} functions do not do a scan so we provide
a liblvm function that does a scan.
Author: Dave Wysochanski <dwysocha@redhat.com>
These functions provide the capability of enumerating all vgnames and
vgids in the system. They do not do a scan of the system.
Author: Dave Wysochanski <dwysocha@redhat.com>
Caller must free the memory of the uuid / name returned.
This may not be the best memory management policy since it may lead to
memory leaks if the caller has code like this:
if (!lvm_vg_get_name(vg))
Maybe we don't care - if we do we can use pools tied to handles later
or some other scheme.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Acked-by: Thomas Woerner <twoerner@redhat.com>
- Use vgmem pool to allocate a list of lvm_*_list structs
- Allocate a new list each call (list may have changed since last call)
- Add to liblvm's exported symbols
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Acked-by: Thomas Woerner <twoerner@redhat.com>
- pv_t, vg_t, lv_t
- include libdevmapper.h: needed for struct dm_list
These list structures will be needed in later APIs to return a list of
handles to one object, given another object. For example, lvm_vg_list_lvs()
will return a list of LV handles (lv_t's) given a VG handle (vg_t). We
need a structure to do this so we define the LV structure, as well as the
other structures at this point.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Some of the error interface is still TBD. Rather than exporting a lot
of codes, etc, just use a simple pass / fail. The allows our unit test
to not segfault if trying to create a VG that already exists.
lvm_vg_open() calls internal vg_read() function which is the entry point
for reading an existing VG. In addition to the mode, we include a 'flags'
parameter for future extensions.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Reverts some of my 'cleanup' from last night. For now we will use pass/fail
on API calls (either 'int' return or NULL/non-NULL handle), then use
lvm_errno() to get more specific errors.
Author: Dave Wysochanski <dwysocha@redhat.com>
