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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These functions are really identical but for clarity I made them separate
functions in this patch.
Should be no functional change.
Author: Dave Wysochanski <dwysocha@redhat.com>
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.
Author: Dave Wysochanski <dwysocha@redhat.com>
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.
Author: Dave Wysochanski <dwysocha@redhat.com>
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.
Author: Dave Wysochanski <dwysocha@redhat.com>
Introduce 'lock_vg_from_first' flag to retain which vg was locked first.
Should be no functional change.
Author: Dave Wysochanski <dwysocha@redhat.com>
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.
Author: Dave Wysochanski <dwysocha@redhat.com>
Full changes
- Fix vgextend error path when lock_vol(VG_ORPHANS) fails
- Move lock_vol(VG_ORPHANS) before archive(vg) - safe & simpler error paths
- Remove legacy comment/code that no longer applies
Found in review - Milan Broz <mbroz@redhat.com>
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Adds pe_align_offset to 'struct physical_volume'; is initialized with
set_pe_align_offset(). After pe_start is established pe_align_offset is
added to it.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
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>
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>
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 72a41480ba66d7dc2d05ef8583080b6b08208507
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>
We provide a lock type that behaves like no_locking, but is not
clustered. Moreover, it also forbids any write locks. This magically (and
consistently) prevents use of clustered VGs, or changing local VGs with
--ignorelockingfailure. As a bonus, we can remove the special hacks in a few
places. Of course, people looking for trouble can always set their locking_type
to 0 to override.
In _process_one_vg, we should never proceed if the VG read fails with certain
conditions. If we cannot allocate or construct the volume_group structure,
we should not proceed - this is true regardless of the tool calling the
iterator. In other cases, when the volume group structure is constructed but
there is some error (PVs missing, metadata corrupted, etc), some tools may
want to process the VG while others may not.
Author: Dave Wysochanski <dwysocha@redhat.com>
