| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
When checking the command line syntax that was used, don't
check lp->type_str which is set in other ways when determining
the type to use, and may not be exactly what was on the
command line.
|
| |
|
|
|
| |
This was missing from the mapping of syntax to each
operation.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 237f84e0383c7e3003050be7c072ee0a092fd426.
This case failed:
lvcreate --type raid1 -m1 -l2 vg99
lvcreate -aey -l2 -s vg99/lvol0
lvconvert -m2 vg99/lvol0
|
| | |
|
| | |
|
| |
|
|
| |
lp->thin already holds the result of the cmdline arg resolution.
|
| |
|
|
|
| |
(--type thin still needs this for lvcreate - more logic should be
shared between lvcreate and lvconvert)
|
| | |
|
| |
|
|
|
| |
Simpler to delay it all until the actual LV being changed is available,
rather than having it split in two parts.
|
| |
|
|
|
|
| |
Move it all into get_stripe_params().
Some code paths missed --stripesize checks.
E.g. lvcreate --type raid4 -i1
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
linear to raid1, the linear wasnt't switched to the
raid1 mapping, thus creating the false impression of
resilience.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
on any thin snap external origin LV which caused a segfault
when none existed as exposed by the vgsplit-thin.sh test.
Only call lv_is_on_pvs() if an external origin LV actually
exists and correct the related splitting logic.
|
| |
|
|
|
|
|
|
|
| |
When converting to a cache lv, tests were hanging with a prompt for
"Do you want wipe existing metadata of cache pool volume
To preserve cache metadata add option "--zero n".
WARNING: Reusing mismatched cache pool metadata MAY DESTROY YOUR DATA!"
This is new.
|
| |
|
|
|
|
|
|
|
|
|
| |
When a client is doing a wait on a job, any other clients will hang
when trying to do anything with the service. This is caused by
the wait code which was placing the thread that handles
incoming dbus requests to sleep until either the timeout expired or
the job operation completed.
This change creates a thread for the wait request, so that the thread
processing incoming requests can continue to run.
|
| |
|
|
|
|
|
|
| |
with respect to the changed, configurable default behaviour
introduced with commit 7eb79091937d.
E.g. raid default of 2 stripes rather than number of PVs in the VG
or on the command line minus one.
|
| |
|
|
|
| |
(with backward compatible settings user as well to check old logic
is still available when needed).
|
| | |
|
| |
|
|
| |
and smaller
|
| | |
|
| |
|
|
|
| |
commit 8f62b7bfe5 and add comment for the member
to 'struct lv_segment'
|
| |
|
|
|
|
| |
Fix a regression from commit 4420d41f, in which the
check was skipped for splitting a thin pool and an
external origin.
|
| |
|
|
|
|
|
| |
The syntax for converting an LV to a thin LV
included an unnecessary --thin option. I was
probably still confused about these options
when writing this.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
General RAID and RAID segment type specific checks are added
to merge.c. New static _check_raid_seg() is called on each segment
of a RaidLV (which have just one) from check_lv_segments().
New checks caught some unititialized segment members
which are addressed here as well:
- initialize seg->region_size to 0 in lvcreate.c for raid0/raid0_meta
- initialize list seg->origin_list in lv_manip.c
|
| |
|
|
| |
Tool produced warning for non-zeroing thin-pools.
|
| | |
|
| |
|
|
|
|
|
|
| |
Add matching support for -Z option also we doing full conversion
to cache-pool.
Extending coversion message to show which pool type is created
and whether the metadata will be wiped or remain unmodified.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to 27a767d5e8cedf9cac31eb3562cf8fdd4aa88b7c.
Tunning behavior in a way we always prompt when option --zero is NOT specified.
Without -Z lvm expects user wants to 'reset' cache-pool metadata
(they could have been splitted from some cached LV)
If user doesn't want to zero metadata he needs to specify -Zn.
User may also avoid prompting for zeroing by using -Zy for
cache-pool (basically equals using --yes without -Z being given)
(unlike full convert case, there is no cache-pool being converted,
so there is not 'uncoditional' prompt in this case).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When volume was lvconvert-ed to a thin-volume with external origin,
then in case thin-pool was in non-zeroing mode
it's been printing WARNING about not zeroing thin volume - but
this is wanted and expected - so nothing to warn about.
So in this particular use case WARNING needs to be suppressed.
Adding parameter support for lvcreate_params.
So now lvconvert creates 'normal thin LV' in read-only mode
(so any read will 'return 0' for a moment)
then deactivate regular thin LV and reacreate in 'final R/RW' mode
thin LV with external origin and activate again.
|
| |
|
|
|
| |
Tests automatic update of PV header (its "extension" part) to recent
version.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, the automatic update from older to newer version of PV extension
header happened within vg_write call. This may have caused problems under
some circumnstances where there's a code in between vg_write and vg_commit
which may have failed. In such situation, we reverted precommitted metadata
and put back the state to working version of VG metadata.
However, we don't have revert for PV write operation at the moment. So
if we updated PV headers already and we reverted vg_write due to failure
in subsequent code (before vg_commit), we ended up with lost VG metadata
(because old metadata pointers got reset by the PV write operation).
To minimize problematic situations here, we should put vg_write and
vg_commit that is done after PV header rewrites as close to each
other as possible.
This patch moves the automatic PV header rewrite for new extension
header part from vg_write to _vg_read where it's done the same way
as we do any other VG repairs if detected during VG read operation
(under VG write lock).
|
| |
|
|
| |
reported string
|
| | |
|
| |
|
|
|
|
|
|
|
| |
If the VG holding the global lock is removed, we can indicate
that as the reason for not being able to acquire the global
lock in subsequent error messages, and can suggest enabling
the global lock in another VG. (This helpful error message
will go away if the global lock is enabled in another VG,
or if lvmlockd is restarted.)
|
| | |
|
| |
|
|
|
| |
A warning seems too severe for this message, so leave it
out until there's a better idea.
|
| |
|
|
|
| |
Only print this for shared VGs, and include the
time it may take for sanlock.
|
| | |
|
| |
|
|
| |
Show in hex not decimal.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
to include the LV type
|
