1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Commit Graph

12205 Commits

Author SHA1 Message Date
Peter Rajnoha
b077e7374f metadata: do not repair missing PV_EXT_USED flag for PVs belonging to foreign VG
The host that owns foreign VGs is responsible for fixing up PV_EXT_USED
flag - the same already applies to repairing any inconsistent VG.

This patch also moves the iteration over vg->pvs inside
_check_or_repair_pv_ext fn - it's cleaner this way.
2016-02-17 10:19:24 +01:00
Peter Rajnoha
13f3e92632 refactor: add common _is_foreign_vg fn 2016-02-16 13:44:48 +01:00
Peter Rajnoha
45be3c875f pv: use pv->fmt to check for fake PVs, not pv->vg
pv->vg is not set yet during pvcreate processing. Use pv->fmt instead to
check for these fake PVs (all normal PVs have format defined, devices
which are not PVs don't have this set).

This fixes commit 0000db7f98.
2016-02-15 15:52:13 +01:00
Peter Rajnoha
099d99975c cleanup: make the message about marked PVs consistent with the others 2016-02-15 15:20:23 +01:00
Peter Rajnoha
cc9e683adc toollib: skip PV if system ID is used and PV marked as used but metadata missing
If we know that a PV belongs to some VG and we're missing metadata
(because we have only those PV(s) from VG present in the system that
don't have metadata areas), we should skip such PV when processing
under system ID.

This is because we know that the PV belongs to some VG, but we
really can't decide whether it matches system ID unless the VG
metadata is present again.
2016-02-15 15:17:36 +01:00
Peter Rajnoha
0000db7f98 pv: mark fake PVs as not used
Some of the PVs are not even orphan PVs - they're fake PVs - this can
happen if we're listing all devices with "pvs -a". Such PV must not
be marked as used.
2016-02-15 14:46:31 +01:00
Peter Rajnoha
abbaeef096 cleanup: use is_used_pv fn to detect whether PV is in use while reporting pv_free field 2016-02-15 13:30:37 +01:00
Peter Rajnoha
698e0eb851 WHATS_NEW: PV_EXT_USED flag and related 2016-02-15 13:07:35 +01:00
Peter Rajnoha
8ad93874d6 tests: fix tests checking pv_attr - there's a new bit now 2016-02-15 12:44:46 +01:00
Peter Rajnoha
a4e25f4381 tests: add pv-ext-flags.sh test
Testing PV extension flags. Currently, there's only one PV extension
flag present - the PV_EXT_USED flag (marking PV as used in a VG).
2016-02-15 12:44:46 +01:00
Peter Rajnoha
2f00d57e6f vg: automatically update to newest PV ext version during vg_write 2016-02-15 12:44:46 +01:00
Peter Rajnoha
9b9f1ae772 format: format_text: add pv_needs_rewrite to format_handler and implemention for format_text 2016-02-15 12:44:46 +01:00
Peter Rajnoha
08de88535e report: identify used PVs in pv_attr field with 'u' char 2016-02-15 12:44:46 +01:00
Peter Rajnoha
db494d7d34 report: always display 0 for pv_free field if we don't have any mda and PV is marked as used at the same time 2016-02-15 12:44:46 +01:00
Peter Rajnoha
d84a80afb5 backup: backup_restore_vg: register PVs that need writing via vg->pvs_to_write list
The backup_restore_vg is used directly for restoring the VG from backup.
It's also used to do the VG conversions from one metadata format to
another which means vgconvert calls backup_restore_vg too.

When restoring VG from backup, we need to rewrite/write PV headers as
PVs may have been orphans before and now they're becoming part of some
VG - we need to write the PV_EXT_USED flag at least.

When using the backup_restore_vg for vgconvert, we need to write
completely new PV header in different format.

Avoid the special "pv_write" call and handling that was used before
this patch in vgconvert (vgconvert_single function to be more precise)
and reuse existing internal interface to register PV header for writing
(or rewriting) via vg->pvs_to_write list instead like we do it elsewhere
in the code.

This patch also resolves a problem in which PV headers with target
format were written in the vgconvert_single fn as orphans and VG
metadata were added later on - this was a tiny hack actually.
We can't do this now - we need to write the PV as belonging
to a VG because otherwise the PV_EXT_USED flag won't be written
properly (if the PV header is written as orphan, the PV_EXT_USED
is set to 0, of course, even though metadata are attached later).
So this patch removes this tiny inconsistency which was passing
just fine before because we didn't have any relation to the VG
in PV header before. Now we have the PV_EXT_USED flag which says
the "PV is used in some VG".
2016-02-15 12:44:46 +01:00
Peter Rajnoha
531ced90dc metadata: _vg_read: check if PV_EXT_USED flag is set correctly for non-orphan PVs and do a repair if needed
The same check as we already do for orphan PVs, just the other way
round now: if the PV is surely part of some VG and any PV the VG
contains does not have the PV_EXT_USED flag set, repair it.

For example - /dev/sda here is in VG vg and it's incorrectly not
marked as used by PV_EXT_USED flag:

pvs --binary -o pv_ext_vsn,pv_in_use
  WARNING: Volume Group vg is not consistent.
  WARNING: Repairing Physical Volume /dev/sda that is in Volume Group vg but not marked as used.
  PV         VG     Fmt  Attr PSize   PFree   ExtVsn PInUse
  /dev/sda   vg     lvm2 a--  124.00m 124.00m      2      1
2016-02-15 12:44:46 +01:00
Peter Rajnoha
f75e42c06c report: add pv_ext_vsn field to display PV header extension version used
For example:

$ pvs -o pv_name,vg_name,pv_ext_vsn,pv_in_use
  PV         VG     ExtVsn InUse
  /dev/sda               2
  /dev/sdb   vg          2    used
  /dev/vda2  fedora      1    used
2016-02-15 12:44:46 +01:00
Peter Rajnoha
e0b1415105 metadata: check for PV extension version before doing any checks on PV extension flags
PV header extension versions:
  0 - the original PV without any extensions
  1 - bootloader area support added
  2 - PV_EXT_USED flag support added

So do the associated checks related to PV_EXT_USED flag only if
PV header extension found is of version 2 and higher.
2016-02-15 12:44:46 +01:00
Peter Rajnoha
d97f1c89de metadata: _vg_read: check if PV_EXT_USED flag is set correctly for orphan PVs and do a repair if needed
If we know that the PV is orphan, meaning there's at least one MDA on
that PV which does not reference any VG and at the same time there's
PV_EXT_USED flag set, we're certainly in an inconsistent state and we
need to fix this.

For example, such situation can happen during vgremove/vgreduce if we
removed/reduced the VG, but we haven't written PV headers yet because
vgremove stopped abruptly for whatever reason just before writing new
PV headers with updated state, including PV extension flags (and so the
PV_EXT_USED flag).

However, in case the PV has no MDAs at all, we can't double-check
whether the PV_EXT_USED is correct or not - if that PV is marked
as used, it's either:
  - really used (but other disks with MDAs are missing)
  - or the error state as described above is hit

User needs to overwrite the PV header directly if it's really clear
the PV having no MDAs does not belong to any VG and at the same time
it's still marked as being in use (pvcreate -ff <dev_name> will fix this).

For example - /dev/sda here has 1 MDA, orphan and is incorrectly marked
with PV_EXT_USED flag:

$ pvs --binary -o+pv_in_use
  WARNING: Found inconsistent standalone Physical Volumes.
  WARNING: Repairing flag incorrectly marking Physical Volume /dev/sda as used.
  PV         VG     Fmt  Attr PSize   PFree   InUse
  /dev/sda          lvm2 ---  128.00m 128.00m     0
2016-02-15 12:44:46 +01:00
Peter Rajnoha
3436d5b791 report: add pv_in_use field to display whether PV is in use or not
For example:

$ pvs -o pv_name,vg_name,pv_in_use
  PV         VG     InUse
  /dev/sda   vg      used
  /dev/sdb
  /dev/sdc           used

(sda is part of vg - it's used
 sdb is not part of vg - it's not used
 sdc is part of vg, but MDAs missing - it's used)
2016-02-15 12:44:46 +01:00
Peter Rajnoha
b6e3080fff pv: _pvcreate_write: do label removal and zeroing only if creating a new PV 2016-02-15 12:44:46 +01:00
Peter Rajnoha
73f1d444c8 pv: issue different message of different type when we're overwriting existing PV header instead of creating a new one
Scenario:

$ pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created

We're adding the PV to a VG.

Before this patch:
$ vgcreate vg /dev/sda
  Physical volume "/dev/sda" successfully created
  Volume group "vg" successfully created

With this path applied:
$ vgcreate vg /dev/sda
  Volume group "vg" successfully created

...and verbose log containing: "Physical volume "/dev/sda" successfully written"
2016-02-15 12:44:46 +01:00
Peter Rajnoha
52999133a3 pv: check for the PV_EXT_USED flag and deny pvcreate/pvchange/pvremove/vgcreate on such PV (unless forced)
Make sure we won't use a PV that is already marked as used. Normally,
VG metadata would stop us from doing that, but we can run into a
situation where such metadata is missing because PVs with MDAs
are missing and the PVs left are the ones with 0 MDAs.

(/dev/sda in this example has 0 MDAs and it belongs to a VG,
but other PVs with MDA are missing)

$ pvs -o pv_name,pv_mda_count /dev/sda
  PV         #PMda
  /dev/sda       0

$ pvcreate /dev/sda
  PV '/dev/sda' is marked as belonging to a VG but its metadata is missing.
  Can't initialize PV '/dev/sda' without -ff.

$ pvchange -u /dev/sda
  PV '/dev/sda' is marked as belonging to a VG but its metadata is missing.
  Can't change PV '/dev/sda' without -ff.
  Physical volume /dev/sda not changed
  0 physical volumes changed / 1 physical volume not changed

$ pvremove /dev/sda
  PV '/dev/sda' is marked as belonging to a VG but its metadata is missing.
  (If you are certain you need pvremove, then confirm by using --force twice.)

$ vgcreate vg /dev/sda
  Physical volume '/dev/sda' is marked as belonging to a VG but its metadata is missing.
  Unable to add physical volume '/dev/sda' to volume group 'vg'.
2016-02-15 12:44:46 +01:00
Peter Rajnoha
d320d9c52b pv: format-text: store PV_EXT_USED flag if PV is used and unset it otherwise
When adding a PV to VG, set the PV_EXT_USED flag in PV header and
vice versa - if the PV is no longer in a VG, unset the flag.
2016-02-15 12:44:46 +01:00
Peter Rajnoha
10128c9bd6 metadata: schedule PV for header rewrite if adding a PV to VG or restoring VG
When adding PV to VG, we need to rewrite PV header as there's a flip
in PV_EXT_USED flag. The same applies if we're restoring VG from backup.
2016-02-15 12:44:46 +01:00
Peter Rajnoha
2950adc2ab metadata: add_pv_to_vg: add 'new_pv' arg to state if the PV is about to be created 2016-02-15 12:44:46 +01:00
Peter Rajnoha
4cbaaa5c98 pv: add is_used_pv fn 2016-02-15 12:44:46 +01:00
Peter Rajnoha
71ea2e1602 lvmcache/lvmetad: cache PV extension version
Store PV extension version in lvmcache/lvmetad for use throughout the code.
2016-02-15 12:44:46 +01:00
Peter Rajnoha
7593221f94 lvmcache/lvmetad: cache PV extension flags
Store PV extension flags in lvmcache/lvmetad for use throughout the code.
2016-02-15 12:44:46 +01:00
Peter Rajnoha
54b41db9a6 metadata: introduce PV_EXT_USED flag and bump PV_HEADER_EXTENSION_VSN 2016-02-15 12:44:46 +01:00
Peter Rajnoha
a522af93b7 format: add FMT_PV_FLAGS to indicate format supports PV flags 2016-02-15 12:44:46 +01:00
Peter Rajnoha
4361543f3e refactor: rename struct pv_to_create --> struct pv_to_write
We'll use this struct in subsequent patches for PVs which should
be rewritten, not just created. So rename struct pv_to_create to
struct pv_to_write for clarity.
2016-02-15 12:44:45 +01:00
Alasdair G Kergon
952498ef4d post-release 2016-02-15 10:48:55 +00:00
Alasdair G Kergon
228b8245e4 pre-release 2016-02-15 10:35:16 +00:00
Peter Rajnoha
672deaebc5 man: pvresize: remove old comment about inability to resize PV with more mdas 2016-02-12 16:29:47 +01:00
Zdenek Kabelac
337aa4ca8e tests: indent
Better bash indention
2016-02-12 11:59:42 +01:00
Ondrej Kozina
0daf9d7ac5 pvmove: fix possible memory pool corruption
This is a hotfix for a bug introduced in
6d7dc87cb3.

The bug description: First we allocate memory for
processing handle (at an address 1) then we
allocate some memory on the same pool for later use
in pvmove_poll function inside the process_each_pv
function (at an address 2). After we jump out of
process_each_pv we called destroy_processing_handle.
As a result of destroying the handle memory pool could
deallocate all memory at address 1 or higher. The
pvmove_poll function tried to copy a memory allocated
at address 2 that could be returned to the system.
If it was so it led to segfault.

We need to rethink proper fix but in the same time
cmd->mem pool is recreated per each lvm command so
this should not cause problems even when we run
multiple commands in lvm shell.

A valgrind snapshot of the corruption:

Invalid read of size 1
    at 0x4C29F92: strlen (mc_replace_strmem.c:403)
    by 0x5495F2E: dm_pool_strdup (pool.c:51)
    by 0x1592A7: _create_id (pvmove.c:774)
    by 0x159409: pvmove_poll (pvmove.c:796)
    by 0x1599E3: pvmove (pvmove.c:931)
    by 0x15105B: lvm_run_command (lvmcmdline.c:1655)
    by 0x1523C3: lvm2_main (lvmcmdline.c:2121)
    by 0x1754F3: main (lvm.c:22)
Address 0xf15df8a is 138 bytes inside a block of size 8,192 free'd
    at 0x4C28430: free (vg_replace_malloc.c:446)
    by 0x5494E73: dm_free_wrapper (dbg_malloc.c:357)
    by 0x5495DE2: _free_chunk (pool-fast.c:318)
    by 0x549561C: dm_pool_free (pool-fast.c:151)
    by 0x164451: destroy_processing_handle (toollib.c:1837)
    by 0x1598C1: pvmove (pvmove.c:903)
    by 0x15105B: lvm_run_command (lvmcmdline.c:1655)
    by 0x1523C3: lvm2_main (lvmcmdline.c:2121)
    by 0x1754F3: main (lvm.c:22)
2016-02-12 11:40:33 +01:00
Zdenek Kabelac
a077a64983 tests: update test
Upgrade test to count with much faster dmeventd work thanks
to low_watter_mark support.

Fix some wrong tests.
2016-02-12 10:21:07 +01:00
Zdenek Kabelac
befe0078ad gcc: better code for older compiler
Address this gcc warning:

metadata/lv.c:243: warning: initialized field overwritten
metadata/lv.c:243: warning: (near initialization for 'status.seg_status')

Present with e.g.: gcc version 4.3.2 (Debian 4.3.2-1.1)
2016-02-12 10:17:39 +01:00
Zdenek Kabelac
ba111e7f4a tests: check for automated dmeventd resize
Watermark support should handle relatively quickly data LV resizes.
So check if it does what is expected.
2016-02-11 18:38:40 +01:00
M.H. Tsai
53058e5234 debug: cut_and_paste type in message
Typo in debug message.
2016-02-11 18:38:40 +01:00
Zdenek Kabelac
cc23fdbd13 cleanup: update messages 2016-02-11 18:38:40 +01:00
Zdenek Kabelac
5a32d2c1d9 cleanup: drop unneeded assigns 2016-02-11 18:35:07 +01:00
Zdenek Kabelac
032cf8ade6 cleanup: relocate function to vg.c 2016-02-11 18:35:06 +01:00
Zdenek Kabelac
acf7815aca cleanup: stripes_extents
Simplify calculation of extents rounding needed for
segment size.

Segment size has to divisible by 'extent count' needed to contain
whole stripe. LVM currently does not support stripes across segment.

In case the stripe size is bigger then extent size,
require bigger rounding.
2016-02-11 18:35:06 +01:00
Zdenek Kabelac
740d27f9fe cleanup: rename usepolicies
Switch to ARG name without '_' in the middle (like all others args).
2016-02-11 18:35:06 +01:00
Zdenek Kabelac
3f916e8285 lvresize: check for given parameters
Check ac_ value as passed args.
Also drop reseting 'computed' values - since they get
assigned values later.
2016-02-11 18:35:06 +01:00
Zdenek Kabelac
0baf66a992 dm: alloc always 8byte aligned
Fixing regression caused by 197b5e6dc7.
So the 'TODO' part now finally know the answer - there is 'sparc64'
architecture which imposes limitation to read 64b words only through
64b aligned address.

Since we never could know how is the user going to use the returned
pointer and the userusually expects it's aligned on the highest CPU
required alignement, preserve it also for char*.

Fixes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809685
Reported-by: Anatoly Pugachev <matorola@gmail.com>
2016-02-11 18:35:05 +01:00
M.H. Tsai
f91622741f dm: fix thin-pool targer params order
Wrong thin-pool feature flag ordering in dm table: It will lead to
unnecessary table reload.

Fix it by placeing feature flags in order they are returned from the
kernel so current 'table line diff' code will not see a difference.
2016-02-11 18:32:24 +01:00
M.H. Tsai
e32e793c43 lvconvert: enable spare creation during conversion
Let user control pool metadata spare creation after repair as
the VG might not have enough free space.
2016-02-11 18:30:40 +01:00