Making adjustments to go along with the changes to the kernel.
A patch to the kernel, adding the 'luid' field to dm_ulog_request,
will allow us to properly identify log instances. We will now
be able to definitively identify which logs are to be removed/
suspended/resumed. This replaces the old faulty behavior of
assuming the logs were the same if they had the same UUID and
incrementing/decrementing a reference count.
Dave Wysochanski [Tue, 28 Jul 2009 15:14:56 +0000 (15:14 +0000)]
Add an open_mode to the vg struct for liblvm - enforce read / write semantics.
For now, a simple way to enforce the read/write semantics is to just save the
open mode of the VG. If the caller uses lvm_vg_create, the mode is write.
The caller using lvm_vg_open can use either read or write to open the VG.
Once we have this, we enforce the permissions on each API call and don't allow
a caller to modify a VG that has not been opened properly.
This may be better combined with the locking mode, but I view that as future
cleanup, past this initial release. The intial release should enforce the
basic object semantics though, as described in the lvm.h file.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Dave Wysochanski [Tue, 28 Jul 2009 13:17:04 +0000 (13:17 +0000)]
Add lvm_vg_get_seqno, updating lvm.h and unit test.
Adding the ability to get the seqno is important for an application to
determine if something has changed in a VG. Otherwise, the only way to
know is to open the VG with write permission and hold the handle.
Dave Wysochanski [Tue, 28 Jul 2009 00:36:58 +0000 (00:36 +0000)]
Update lvm.h to address feeback.
This addresses a a large amount of Alasdair's review. Subsequent patches
will address remaining issues.
Addressed:
// FIXME Mention that's also required on error.
// FIXME Be consistent in terminology. It's called "system_dir" then last sentence says "system directory setting". Is it referring to "system_dir" there or something else?
// FIXME Mention it frees all resources and cannot be used subsequently?
// FIXME What does "any system configuration" mean?
// FIXME Expand on that explanation a bit, now that we know what the other fns look like.
// FIXME Not sure about that - it needs to scan sometimes. "will not" or "might not" ?
// FIXME: That's a FIXME in the code!!!
// FIXME What does "copied" mean in this context???
// FIXME Say what struct the returned struct dm_list is a list of...
// FIXME "This API" ? This function creates an object in memory?
// FIXME This function commits the Volume Group object referenced by the VG handle to disk?
// FIXME Where is "Name" defined? Absolute pathname?
Outstanding:
// FIXME Version function first? No structs or handles needed for that.
// FIXME Sort out this alignment. "Set an" directly below "system_dir" looks awful. Indent differently? More blank lines?
// FIXME Check how doxygen processes this. E.g. "return: LVM handle. You must use lvm_error() to check there were no errors and confirm that the handle is valid for passing to other functions."
// FIXME Find a better name. lvm_init.
// FIXME Consider renaming according to the new name for lvm_create.
// FIXME Please can we use dm_malloc throughout?
Dave Wysochanski [Mon, 27 Jul 2009 21:02:17 +0000 (21:02 +0000)]
Add lvm_config_override - allow caller to override config, similar to --config.
Allowing the caller to override the LVM configuration with an API will
enable them to use things such as device filters.
While very flexible, there is some danger to this API in that it will
make it harder to debug setups that have a changing config and deduce
what might have happened. At some point we may want to limit the scope
of this API but for now it is as open as the --config option to lvm commands.
Update exported symbols. When I renamed lvm_reload_config to lvm_config_reload
I forgot to rename so I renamed that one here.
This I believe is the last liblvm API for now. ;-)
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Dave Wysochanski [Mon, 27 Jul 2009 17:44:29 +0000 (17:44 +0000)]
Add lvm_vg_reduce to liblvm2app
Extend lvm_vg_write to remove pvs removed in lvm_vg_reduce. The lvm
volume_group internal structure removed_pvs is used for that. The list is
empty afterwards.
Add new test for vg->pvs emptyness to lvm_vg_write to prevent to write empty
vgs. This is needed because of lvm_vg_reduce and lv_vg_create, which creates
empty vgs.
Signed-off-by: Thomas Woerner <twoerner@redhat.com> Acked-by: Dave Wysochanski <dwysocha@redhat.com>
Author: Dave Wysochanski <dwysocha@redhat.com>
Dave Wysochanski [Mon, 27 Jul 2009 17:43:39 +0000 (17:43 +0000)]
Add vg_reduce to metadata.c and metadata-exported.h
This function behaves a little bit different than vg_reduce_single, because
it allowes to remove even the latest pv. This has been done to be consistent
to lvm_vg_create, which creates an empty vg.
removed_pvs has been added to the volume_group struct. vg_reduce adds remove
pvs to this list to be able to commit the changes for the pvs in lvm_vg_comm
in liblvm2app.
Initialize removed_pvs list in format-specific volume_group constructors.
Ideally, we should have a base constructor here that initializes the general
non-format specific members of struct volume_group. But until then, there
are multiple places to initialize these members. Maybe a better patch would
be a base constructor patch for struct volume_group. That is more work
though.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Author: Dave Wysochanski <dwysocha@redhat.com>
Dave Wysochanski [Mon, 27 Jul 2009 11:00:17 +0000 (11:00 +0000)]
Update error return and comments for lvm_list_vg_names/uuids.
The two liblvm functions that return a list of vgnames and vguuids use
cmd->mem to allocate the list. Make it clear to the caller that this
memory will be freed when the LVM handle is freed.
Clean up and clarify the return value of the functions. In the
case of a memory allocation error, add a couple log_errnos to the internal
code, and make it clear that memory allocation returns a NULL pointer.
If there are no VGs in the system, the list returned is an empty list.
Make a note of the fact that currently we return hidden VG names, how
these can be detected (always start with "#"), and that they should
not be used.
Dave Wysochanski [Sun, 26 Jul 2009 20:29:56 +0000 (20:29 +0000)]
Update test/api/*.c to use consistent liblvm error returns.
For now, liblvm will return -1 (fail) / 0 (success) or
NULL (fail) / non-NULL (success). Upon failure, lvm_errno and
lvm_errmsg should be used to determine the precise error.
Dave Wysochanski [Sun, 26 Jul 2009 20:28:59 +0000 (20:28 +0000)]
Update liblvm status return codes to be consistent.
For now, we use the following scheme.
For APIs that return an int, success is 0, fail is -1.
APIs that return handles, success is non-NULL, fail is NULL.
At this early stage, liblvm error handling mechanism is subject to change,
but for now we go with this simple scheme consistent with system
programming.
Dave Wysochanski [Sun, 26 Jul 2009 16:35:57 +0000 (16:35 +0000)]
Update lvm.h - comments describing function behavior, divide into sections.
Hard to divide into smaller patches because of the moving around and
commenting, so just put in the new file diffs. We will review and can
update as necessary.
Dave Wysochanski [Sun, 26 Jul 2009 14:36:52 +0000 (14:36 +0000)]
Add lvm_vg_remove_lv liblvm function.
Add a very simple version of lvm_vg_remove_lv.
Since we currently can only create linear LVs, this simple remove function
is adequate. We must refactor lvremove_single a bit.
Dave Wysochanski [Sun, 26 Jul 2009 13:06:59 +0000 (13:06 +0000)]
Add most all liblvm 'get' functions needed for anaconda.
Add the most straightforward 'get' functions required for anaconda.
These are the ones that return simple uint64_t values.
The other more complex ones involve the lv_attr bits. These will
come in a separate patch series since each lv_attr bit will be returned
in a separate API instred of returning the string and requiring the
user to parse it.
Dave Wysochanski [Sun, 26 Jul 2009 12:41:09 +0000 (12:41 +0000)]
Refactor a few report field calculations into separate functions.
For liblvm 'get' functions, we should share code with the reporting functions.
This means we need common code to return the values for the fields.
In this patch we refactor a few of the fields needed in liblvm.
Unfortunately, for the simple fields that do derefernces of structure
members (for example, vg_extent_count), we cannot call the common function
from the reporting infrastructure without more refactoring. The reason is
that the dereference of the simple fields is done deep inside the reporting
code (to get the generic "data" pointer), and the display function is a
generic 'size32' function. We can fix these issues later with more
refactoring.
Should be no functional change and the testsuite should cover any possible
regressions. The only fields in the report affected by this patch are:
vg_size, vg_free, and pv_mda_count.
Dave Wysochanski [Sun, 26 Jul 2009 02:33:35 +0000 (02:33 +0000)]
Move _lvcreate into the internal library and rename to lv_create_single.
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.
Dave Wysochanski [Sun, 26 Jul 2009 02:31:41 +0000 (02:31 +0000)]
Move percent_t from struct lvcreate_params to struct lvcreate_cmdline_params.
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.
Dave Wysochanski [Sun, 26 Jul 2009 02:31:18 +0000 (02:31 +0000)]
Refactor extents calculations / updates in _lvcreate.
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.
Dave Wysochanski [Sun, 26 Jul 2009 02:30:57 +0000 (02:30 +0000)]
Refactor _lvcreate - move *_ARG into _lvcreate_params and get 'cmd' from 'vg'.
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.
Dave Wysochanski [Sun, 26 Jul 2009 01:54:40 +0000 (01:54 +0000)]
Update lvm_vg_extend to do an implicit pvcreate on the device.
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.
Dave Wysochanski [Sun, 26 Jul 2009 01:54:20 +0000 (01:54 +0000)]
Move ORPHAN_VG lock outside pvcreate_single.
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.
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>
Dave Wysochanski [Thu, 23 Jul 2009 23:40:05 +0000 (23:40 +0000)]
Add lvm_{pv|vg|lv}_get_{uuid|name}.
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>
Dave Wysochanski [Thu, 23 Jul 2009 23:39:02 +0000 (23:39 +0000)]
Add lvm_vg_list_{pvs|lvs} - return lists of pv/lv handles for a vg.
- 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>
Dave Wysochanski [Thu, 23 Jul 2009 23:37:24 +0000 (23:37 +0000)]
Add list structure definitions for liblvm objects.
- 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>
Dave Wysochanski [Thu, 23 Jul 2009 01:20:22 +0000 (01:20 +0000)]
Update lvm_vg_create to use NULL / non-NULL return for the time being.
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.
Dave Wysochanski [Wed, 22 Jul 2009 22:24:16 +0000 (22:24 +0000)]
Add lvm_vg_open() to open an existing VG for reading or writing.
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>
git://sourceware.org / lvm2.git / log