Dave Wysochanski [Wed, 30 Sep 2009 16:13:53 +0000 (16:13 +0000)]
Update nightly tests to deal with unit changes.
Now uppercase letters imply Si units, so use lowercase everywhere.
We could stay with uppercase, but then we'd have to deal with rounding, etc.
Also, some output / error messages change slightly (instead of "GB" we're
now saying "GiB").
One test enhancement might be to add some new tests for the units changes
but for now let's just get the test back to passing.
Add global/si_unit_consistency to enable cleaned-up use of units in output.
Add configure --enable-units-compat to set si_unit_consistency off by default.
Use standard output units for 'PE Size' and 'Stripe size' in pv/lvdisplay.
'_emit_areas_line' returns 1 for success and 0 for failure. This always
confuses me, so I've added a comment at the top of the function to
remind me of this.
I also found that 'mirror_emit_segment_line' was returning 0 (return_0)
on failure /and/ success. It now returns 1 for success and 0 for failure -
just like '_emit_areas_line' and its calling function, '_emit_segment_line'.
Dave Wysochanski [Tue, 15 Sep 2009 18:35:13 +0000 (18:35 +0000)]
Add vg_is_resizeable() and cleanup references.
Clean up VG_RESIZEABLE flag by creating vg_is_resizeable().
Update comment - we no longer have ALLOW_RESIZEABLE.
Also use vg_is_exported() in one place missed by earlier patch.
Should be no functional change.
Dave Wysochanski [Tue, 15 Sep 2009 01:38:59 +0000 (01:38 +0000)]
Fix process_each_vg / _process_one_vg when vg_read() returns FAILED_LOCKING.
Remove the checks for vg_read_error() in most of the tools callback
functions and instead make the check in _process_one_vg() more general.
In all but vgcfgbackup, we do not want to proceed if we get any error
from vg_read(). In vgcfgbackup's case, we may proceed if the backup
is to proceed with inconsistent VGs. This is a special case though,
and we mark it with the READ_ALLOW_INCONSISTENT flag passed to
process_each_vg (and subsequently to _process_one_vg).
NOTE: More cleanup is needed in the vg_read_error() path cases.
This patch is a start.
Add lots of missing stack debug messages to tools.
Make readonly locking available as locking type 4.
Fix readonly locking to permit writeable global locks (for vgscan). (2.02.49)
Dave Wysochanski [Mon, 14 Sep 2009 19:44:15 +0000 (19:44 +0000)]
Use vg_is_exported(vg) macro everywhere.
This patch is all just cleanup and no other patch depends on it.
Replace explicit dereference and check with vg_is_exported().
Update a few copyrights and remove unnecessary whitespace.
Should be no functional change.
Dave Wysochanski [Mon, 14 Sep 2009 19:43:11 +0000 (19:43 +0000)]
Add most relevant vg_attr fields as lvm2app 'get' functions.
Of the vgs field vg_attr, a few of the most likely to be used attributes
are clustered, exported, and partial. This patch adds the following 3
functions:
uint64_t lvm_vg_is_clustered(const vg_t vg)
uint64_t lvm_vg_is_exported(const vg_t vg)
uint64_t lvm_vg_is_partial(const vg_t vg)
Peter Rajnoha [Fri, 11 Sep 2009 16:11:25 +0000 (16:11 +0000)]
Move dm_cookie_supported check into dm_udev_get_sync_supprt function.
We don't have to call dm_cookie_supported with dm_udev_get_sync_support
this way. Also, it's necessary for the current code to work properly on
systems without cookie support (older kernels).
Peter Rajnoha [Fri, 11 Sep 2009 16:05:20 +0000 (16:05 +0000)]
Several changes in udev rules:
- add DM_UDEV_RULES_VSN to provide a variable to be checked for in the other
rules (e.g. to check that DM rules are actually installed, we can alternate
functionality in the other rules based on this information, also we have
versioning support for the rules)
- set proper sbin path for dmsetup and blkid, /sbin first, then /usr/sbin.
This is necessary for anaconda to work properly.
- add 'last_rule' for cryptsetup's temporary devices (symlinks in /dev/mapper
only)
Remove 'test' interative api unit tests from 'TARGET' line.
The test/api directory TARGET line will be reserved for non-interactive
unit tests. Building the interactive test can still be done with "make test"
from the test/api dir.
Remove 'test' interative api unit tests from 'TARGET' line.
The test/api directory TARGET line will be reserved for non-interactive
unit tests. Building the interactive test can still be done with "make test"
from the test/api dir.
Update lvm_vg_write() to handle the deferred commit of lvm_vg_write().
Now that we've refactored the internal library functions that do the
vg_remove, we can handle the deferred commit of a lvm_vg_remove() inside
lvm_vg_write(). This makes the VG create/remove API more consistent in
terms of disk commits - they now both require an lvm_vg_write() to commit
the create or remove to disk.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Author: Dave Wysochanski <dwysocha@redhat.com>
Update vg_remove_single_* functions to use the removed_pvs list.
Now that we've split vg_remove_single into two routines, in the first routine
that only manipulates memory, we move the PVs from the vg->pvs list to the
vg->removed_pvs list. Then later, we iterate through this list to write the
removed PVs to disk, which removes them from the volume group and places them
into the internal ORPHAN VG.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Author: Dave Wysochanski <dwysocha@redhat.com>
Split vg_remove_single into 2 functions - the second part commits to disk.
Split vg_remove_single into vg_remove_check (mandatory checks before
vgremove) and vg_remove (do actual remove by committing to disk).
In liblvm, we'd like to provide an consistent API that allows multiple
changes in memory, then let lvm_vg_write() control the commit to disk. In
some cases (for example, lvresize calls fsadm) this may not be possible.
However, since we are using an object model and dividing things into small
operations, the most logical model seems to be the lvm_vg_write model, and
handling the special cases as they arrive. So as best as possible
we move towards this end.
A possible optimization would be to consolidate vg_remove (committing)
code with vgreduce code. A second possible optimization is making vgreduce
of the last device equivalent to vgremove. Today, lvm_vg_reduce fails if
vgreduce is called with the last device, but from an object model perspective
we could view this as equivalent to vgremove and allow it. My gut feel is
we do not want to do this though.
Enforce an alphabetical lock ordering for vgname locks.
Add a new constraint that vgname locks must be obtained in
alphabetical order. At this point, we have test coverage for
the 3 commands affected - vgsplit, vgmerge, and vgrename.
Tests have been updated to cover these commands.
Going forward any command or library call that must obtain
more than one vgname lock must do so in alphabetical order.
Future patches will update lvm2app to enforce this ordering.
Change vgsplit behavior to open/lock first vg based on alphabetical ordering.
If the destination vgname comes before the source vgname, we must open the
destination first because of the locking rules. Thus, do a strcmp and set
the flag based on the comparison.
Refactor vgsplit - reorder _vgsplit_from and _vgsplit_to based on flag.
Slight functional change. If we open the destination first, we cannot
know the 'fmt'. In this case we use the default metadata type unless
the user has specified -M on the cmdline. If not, in most cases this
is fine since we use the LVM2 default metadata type. However, if the
user is specifying a non-default metadata type (e.g. lvm1) and the order
of the names is such that we have to open the destination (vg_to) first,
we have a problem. So in this case, we require the use of -M and vgsplit
will fail with an error if not. I've updated the man page to recommend
the usage of -M in this case.
Refactor vgsplit - create _vgsplit_to function which creates or opens dest vg.
Move the creating/opening of the destination vg into its own function so later
we can reorder the source / destination vg opening based on the alphabetical
lock order rule.
Should be no functional change but code is a bit tricky.
Refactor vgsplit to move existing_vg logic in a separate 'if' statement.
This will aid in future refactorings and allow for us to reorder the source
and destination vg based on alphabetical names.
Should be no functional change.