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

1950 Commits

Author SHA1 Message Date
Alasdair G Kergon
bbcc120e5a pvmove: clean exit on failed pvmove restart
At present, before the pvmove command can be used to restart pvmove
polling, the LVs concerned need to be activated e.g. with lvchange -ay.
2013-09-23 19:46:28 +01:00
Petr Rockai
3df50d822b vgconvert: Do not call lvmetad_vg_remove (path shared with vgcfgbackup). 2013-09-18 12:53:11 +02:00
Petr Rockai
054cf25b5f vgcfgrestore: Remove VG rom lvmetad later, to better deal with errors. 2013-09-18 11:24:58 +02:00
Petr Rockai
a6af611ae1 vgcfgrestore: Remove the VG from lvmetad before overwriting it. 2013-09-18 10:37:29 +02:00
Alasdair G Kergon
68f841fcda dmsetup: Detect invalid sector supplied to message.
atoll doesn't check for errors, so invalid sector numbers were silently
accepted in the "dmsetup message" command.

(Mikulas)
2013-09-18 01:24:19 +01:00
Alasdair G Kergon
6e912d949b tools: Avoid overflow in _get_int_arg.
Use strtoull instead of strtol so that argument size is not cut
to 31 bytes on machines with 32-bit long.

(Mikulas)
2013-09-18 01:16:48 +01:00
Alasdair G Kergon
a3a5f58c21 reporting: Add devtypes command.
Add internal devtypes reporting command to display built-in recognised
block device types.  (The output does not include any additional
types added by a configuration file.)

> lvm devtypes -o help
  Device Types Fields
  -------------------
    devtype_all            - All fields in this section.
    devtype_name           - Name of Device Type exactly as it appears in /proc/devices.
    devtype_max_partitions - Maximum number of partitions. (How many device minor numbers get reserved for each device.)
    devtype_description    - Description of Device Type.

> lvm devtypes
  DevType       MaxParts Description
  aoe                 16 ATA over Ethernet
  ataraid             16 ATA Raid
  bcache               1 bcache block device cache
  blkext               1 Extended device partitions
...
2013-09-18 01:09:15 +01:00
Alasdair G Kergon
ce9a5cc257 debug: Use // for commented out debug #defines
The traditional style used for optional editable definitions
/* #define X	/* */
produces a bogus warning from gcc -Wall.

Rather than suppressing this with -Wno-comment, switch over to
the // comment style.
2013-09-16 20:20:26 +01:00
Jonathan Brassow
82228acfc9 Mirror/Thin: Disallow thinpools on mirror logical volumes
The same corner cases that exist for snapshots on mirrors exist for
any logical volume layered on top of mirror.  (One example is when
a mirror image fails and a non-repair LVM command is the first to
detect it via label reading.  In this case, the LVM command will hang
and prevent the necessary LVM repair command from running.)  When
a better alternative exists, it makes no sense to allow a new target
to stack on mirrors as a new feature.  Since, RAID is now capable of
running EX in a cluster and thin is not active-active aware, it makes
sense to pair these two rather than mirror+thinpool.

As further background, here are some additional comments that I made
when addressing a bug related to mirror+thinpool:
(https://bugzilla.redhat.com/show_bug.cgi?id=919604#c9)
I am going to disallow thin* on top of mirror logical volumes.
Users will have to use the "raid1" segment type if they want this.

This bug has come down to a choice between:
1) Disallowing thin-LVs from being used as PVs.
2) Disallowing thinpools on top of mirrors.

The problem is that the code in dev_manager.c:device_is_usable() is unable
to tell whether there is a mirror device lower in the stack from the device
being checked.  Pretty much anything layered on top of a mirror will suffer
from this problem.  (Snapshots are a good example of this; and option #1
above has been chosen to deal with them.  This can also be seen in
dev_manager.c:device_is_usable().)  When a mirror failure occurs, the
kernel blocks all I/O to it.  If there is an LVM command that comes along
to do the repair (or a different operation that requires label reading), it
would normally avoid the mirror when it sees that it is blocked.  However,
if there is a snapshot or a thin-LV that is on a mirror, the above code
will not detect the mirror underneath and will issue label reading I/O.
This causes the command to hang.

Choosing #1 would mean that thin-LVs could never be used as PVs - even if
they are stacked on something other than mirrors.

Choosing #2 means that thinpools can never be placed on mirrors.  This is
probably better than we think, since it is preferred that people use the
"raid1" segment type in the first place.  However, RAID* cannot currently
be used in a cluster volume group - even in EX-only mode.  Thus, a complete
solution for option #2 must include the ability to activate RAID logical
volumes (and perform RAID operations) in a cluster volume group.  I've
already begun working on this.
2013-09-11 15:58:44 -05:00
Jonathan Brassow
2691f1d764 RAID: Make RAID single-machine-exclusive capable in a cluster
Creation, deletion, [de]activation, repair, conversion, scrubbing
and changing operations are all now available for RAID LVs in a
cluster - provided that they are activated exclusively.

The code has been changed to ensure that no LV or sub-LV activation
is attempted cluster-wide.  This includes the often overlooked
operations of activating metadata areas for the brief time it takes
to clear them.  Additionally, some 'resume_lv' operations were
replaced with 'activate_lv_excl_local' when sub-LVs were promoted
to top-level LVs for removal, clearing or extraction.  This was
necessary because it forces the appropriate renaming actions the
occur via resume in the single-machine case, but won't happen in
a cluster due to the necessity of acquiring a lock first.

The *raid* tests have been updated to allow testing in a cluster.
For the most part, this meant creating devices with '-aey' if they
were to be converted to RAID.  (RAID requires the converting LV to
be EX because it is a condition of activation for the RAID LV in
a cluster.)
2013-09-10 16:33:22 -05:00
Zdenek Kabelac
d89b514e06 cleanup: drop within comment gcc warning
toollib.c:69:24: warning: "/*" within comment
2013-09-09 12:17:11 +02:00
Alasdair G Kergon
10a5838a60 toollib: tweak background forking
Log what is forked and replace #if 1 with DEBUG_CHILD.
2013-09-06 01:49:43 +01:00
Alasdair G Kergon
96880102a3 logging: Write Completed message before resetting. 2013-09-06 01:47:41 +01:00
Alasdair G Kergon
5face2010d tools: Use backgroundfork_ARG for pvscan -b
Change pvscan -b to use a new backgroundfork_ARG instead of
background_ARG so as not to affect pvmove -b and lvconvert -b.
2013-09-06 01:43:24 +01:00
Jonathan Brassow
cc66dedc0e pvmove: Skip pvmove of RAID, thin, snapshot, origin, and mirror LVs in cluster
pvmove of the above types should only have been enabled in single machine
mode.
2013-09-03 13:17:01 -05:00
Peter Rajnoha
3b51f298bb reinstate: commit 82d83a01ce
It now works as supposed. The source of the problem is fixed
by previous commit d2d6a9da52e04f28e1916bcea3f9fda356b6df29.
2013-09-03 16:49:21 +02:00
Peter Rajnoha
008c33a21b tools: add -b/--background for pvscan --cache -aay
Udev daemon has recently introduced a limit on the number of udev
processes (there was no limit before). This causes a problem
when calling pvscan --cache -aay in lvmetad udev rules which
is supposed to activate the volumes. This activation is itself
synced with udev and so it waits for the activation to complete
before the pvscan finishes. The event processing can't continue
until this pvscan call is finished.

But if we're at the limit with the udev process count, we can't
instatiate any more udev processes, all such events are queued
and so we can't process the lvm activation event for which the
pvscan is waiting.

Then we're in a deadlock since the udev process with the
pvscan --cache -aay call waits for the lvm activation udev
processing to complete, but that will never happen as there's
this limit hit with the number of udev processes.

The process with pvscan --cache -aay actually times out eventually
(3min or 30sec, depends on the version of udev).

This patch makes it possible to run the pvscan --cache -aay
in the background so the udev processing can continue and hence
we can avoid the deadlock mentioned above.
2013-09-03 16:49:21 +02:00
Peter Rajnoha
6a5838a69c pvscan: show -aay with --cache for help 2013-09-03 09:51:30 +02:00
Peter Rajnoha
44c1a02c18 revert: commit 82d83a01ce
The commit 82d83a01ce
"autoactivation: refresh existing VG before autoactivation"
causes problems (dangling udev_sync cookies, slow processing
of the pvscan --cache --major --minor call from udev rules)
when the autoactivation handler is run in parallel on
several PVs that belong to the same VG. Revert this patch
until the exact source of the problem is found and then
properly fixed and handled.
2013-09-02 13:53:27 +02:00
Jonathan Brassow
2ef48b91ed pvmove: Allow moving snapshot/origin. Disallow converting and merging LVs
The patch allows the user to also pvmove snapshots and origin logical
volumes.  This means pvmove should be able to move all segment types.
I have, however, disallowed moving converting or merging logical volumes.
2013-08-26 16:36:30 -05:00
Jonathan Brassow
caa77b33f2 pvmove: Fix inability to specify LV name when moving RAID, mirror, or thin LV
Top-level LVs (like RAID, mirror or thin) are ignored when determining which
portions of an LV to pvmove.  If the user specified the name of an LV to
move and it was one of the above types, it would be skipped.  The code would
never move on to check whether its sub-LVs needed moving because their names
did not match what the user specified.

The solution is to check whether a sub-LVs is part of the LV whose name was
specified by the user - not just if there was a name match.
2013-08-26 14:12:31 -05:00
Zdenek Kabelac
6b416f837f thin: support lvchange for data and metadata
Support lvchange operation on stacked thin pool data and metadata
volumes.
2013-08-26 14:55:22 +02:00
Jonathan Brassow
448ff0119f pvmove: Ability to move thin volumes
The previous commit was missing the code to allow moving thin
volumes.
2013-08-23 09:13:14 -05:00
Jonathan Brassow
c59167ec13 pvmove: Add support for RAID, mirror, and thin
This patch allows pvmove to operate on RAID, mirror and thin LVs.
The key component is the ability to avoid moving a RAID or mirror
sub-LV onto a PV that already has another RAID sub-LV on it.
(e.g. Avoid placing both images of a RAID1 LV on the same PV.)

Top-level LVs are processed to determine which PVs to avoid for
the sake of redundancy, while bottom-level LVs are processed
to determine which segments/extents to move.

This approach does have some drawbacks.  By eliminating whole PVs
from the allocation list, we might miss the opportunity to perform
pvmove in some senarios.  For example, if we have 3 devices and
a linear uses half of the first, a RAID1 uses half of the first and
half of the second, and a linear uses half of the third (FIGURE 1);
we should be able to pvmove the first device (FIGURE 2).
	FIGURE 1:
        [ linear ] [ -RAID- ] [ linear ]
        [ -RAID- ] [        ] [        ]

	FIGURE 2:
        [  moved ] [ -RAID- ] [ linear ]
        [  moved ] [ linear ] [ -RAID- ]
However, the approach we are using would eliminate the second
device from consideration and would leave us with too little space
for allocation.  In these situations, the user does have the ability
to specify LVs and move them one at a time.
2013-08-23 08:57:16 -05:00
Peter Rajnoha
99fd710cfd dumpconfig: also mention profilable type if giving hint about known types 2013-08-19 08:32:03 +02:00
Alasdair G Kergon
d8b781e8ab dmsetup: display any message output from kernel
Recent kernels allow messages to respond with a string.
Add dm_task_get_message_response() to libdevmapper to perform some
basic sanity checks and return this.
Have 'dmsetup message' display any response.

DM statistics will make extensive use of this.

(From Mikulas.)
2013-08-16 15:25:39 +01:00
Peter Rajnoha
82d83a01ce autoactivation: refresh existing VG before autoactivation
When autoactivating a VG, there could be an existing VG with exactly
the same PV UUIDs. The PVs could be reappeared after previous
loss/disconnect (for example disconnecting and reconnecting iscsi).

Since there's no "autodeactivation" yet, the mappings for the LVs
from the VG were left in the system even if the device was disconnected.
These mappings also hold the major:minor of the underlying device.
So if the device reappears, it is assigned a different major:minor
pair (...and kernel name). We need to cope with this during
autoactivation so any existing mappings are corrected for any changes.
The VG refresh does that (the vgchange --refresh functionality) -
call this before VG autoactivation.

(If the VG does not exist yet, the VG refresh is NOP)
2013-08-14 14:04:58 +02:00
Alasdair G Kergon
80bcdb93ff filters: check for mpath before opening devs
Split out the partitioned device filter that needs to open the device
and move the multipath filter in front of it.

When a device is multipathed, sending I/O to the underlying paths may
cause problems, the most obvious being I/O errors visible to lvm if a
path is down.

Revert the incorrect <backtrace> messages added when a device doesn't
pass a filter.

Log each filter initialisation to show sequence.

Avoid duplicate 'Using $device' debug messages.
2013-08-13 23:26:58 +01:00
Petr Rockai
0da72743ca vgck: Fix #894136, notice on-disk corruption in spite of lvmetad. 2013-08-13 23:25:49 +02:00
Alasdair G Kergon
1a1d3a10ff vgchange: require confirmation with -c and no VGs
Too many people have been running 'vgchange -cy' by mistake
so add a confirmation prompt.  Use --yes to bypass this.
2013-08-13 18:20:11 +01:00
Jonathan Brassow
bb457adbb6 RAID: Fix bug making lvchange unable to change recovery rate for RAID
Commit ID 8615234c0f failed to include
the actual code changes that were made to fix the bug.  Instead, all
tests went in to validate the bug fix.  This patch adds the missing
code changes.
2013-08-12 12:43:47 -05:00
Jonathan Brassow
8615234c0f RAID: Fix bug making lvchange unable to change recovery rate for RAID
1) Since the min|maxrecoveryrate args are size_kb_ARGs and they
   are recorded (and sent to the kernel) in terms of kB/sec/disk,
   we must back out the factor multiple done by size_kb_arg.  This
   is already performed by 'lvcreate' for these arguments.
2) Allow all RAID types, not just RAID1, to change these values.
3) Add min|maxrecoveryrate_ARG to the list of 'update_partial_unsafe'
   commands so that lvchange will not complain about needing at
   least one of a certain set of arguments and failing.
4) Add tests that check that these values can be set via lvchange
   and lvcreate and that 'lvs' reports back the proper results.
2013-08-09 17:09:47 -05:00
Zdenek Kabelac
e583ff3d2c thin: thin pool can't be external origin
Avoid trying to convert thin-pool to external origin.
2013-08-09 23:04:30 +02:00
Jonathan Brassow
b15278c3dc Mirror/RAID1: When up|down-converting default to segtype of current LV
If there is no RAID support in the kernel but the default mirror
segtype is "raid1", converting legacy mirrors can be problematic.
For example, changing the log type or converting a mirror to a linear
LV does not require the RAID modules to be present.  However, because
lp->segtype is set to be RAID1 by the configuration file, the command
fails.

We should only be setting lp->segtype when converting mirrors if it is
going to change (e.g. to linear or between mirror types).
2013-08-07 16:01:45 -05:00
Zdenek Kabelac
139a62fc0b thin: use pipe_open instead of popen
Use new function to directly exec command and read its output.
2013-08-06 16:19:31 +02:00
Peter Rajnoha
41e64b72ab thin: chunk_size check already part of get_profilable_pool_params fn 2013-08-06 11:46:48 +02:00
Peter Rajnoha
e195b5227e thin: apply VG profile if creating a new thin pool
When creating a new thin pool and there's no profile requested
via "lvcreate --profile ...", inherit any VG profile if it's attached.

Currently this applies to these settings:
  allocation/thin_pool_chunk_size
  allocation/thin_pool_discards
  allocation/thin_pool_zero
2013-08-06 11:42:40 +02:00
Zdenek Kabelac
de0cba0e2d thin: initial --repair support for pools
Initial basic support for repair.
It currently takes pool metadata spare volume, which
is used for recovery.  New spare is created if the volume
is successfuly repaired.

After the operation the previous _tmeta volume is moved
into  _tmeta%d volume and if everything is ok, this volume
could be removed.
New _tmeta needs to be pvmoved to proper place and also
converted to i.e. mirror if it should be mirrored.

Later version will try to automate some steps here.
2013-07-31 15:32:36 +02:00
Alasdair G Kergon
d13e87b9ef cleanup: comments and a message 2013-07-24 22:10:37 +01:00
Zdenek Kabelac
da5284a500 thin: lvconvert cannot convert pool to mirror
Suggest to use _tdata and _tmeta devices for that.
This fixes regression from too relaxed change in
f1d5f6ae81

Without this patch there are some empty LVs created before
mirror code recognizes it cannot continue.

(in release fix)
2013-07-24 17:17:19 +02:00
Jonathan Brassow
d00d45a8b6 Clean-up: Addressing a few FIXME's
Three fixme's addressed in this commit:
1) lib/metadata/lv_manip.c:_calc_area_multiple() - this could be
   safely changed to a comment explaining that currently because
   RAID10 can only have a 2-way mirror, we don't need to know the
   number of stripes.  However, we will need to know that in the
   future if RAID10 is to support more than 2-way mirroring.

2) lib/metadata/mirror.c:_delete_lv() - should have been calling
   _activate_lv_like_model() with 'mirror_lv'.  This is because
   'mirror_lv' is the LV that the overall operation is being
   performed on.  We need to use this LV as the basis for
   determining whether to activate locally, or across the
   cluster, etc.

3) tools/lvcreate.c:_lvcreate_params() - Minor clean-up.  If
   '-m 0' is given, treat it as though the mirroring argument
   was not given (i.e. as though the requested segment type
   was 'stripe' and not mirror).
2013-07-23 14:46:22 -05:00
Peter Rajnoha
31de670318 lvconvert: add more checks for lvconvert --type
The --type mirror requires -m/--mirrrors:

  lvconvert --type mirror vg/lvol0
    --type mirror requires -m/--mirrors
    Run `lvconvert --help' for more information.

The --type raid* is allowed (the checks already existed):

  lvconvert --type raid10 vg/lvol0
    Converting the segment type for vg/lvol0 from linear to raid10 is not yet supported.

The --type snapshot is a synonym to -s/--snapshot:

  lvconvert -s vg/lvol0 vg/lvol1
    Logical volume lvol1 converted to snapshot.

  lvconvert --type snapshot vg/lvol0 vg/lvol1
    Logical volume lvol1 converted to snapshot.

All the other segment types are not supported, e.g.:

  lvconvert --type zero vg/lvol0
    Conversion using --type zero is not supported.
    Run `lvconvert --help' for more information.
2013-07-23 17:13:54 +02:00
Alasdair G Kergon
3670fe92ba cleanup: suppress compiler warning 2013-07-23 13:32:47 +01:00
Petr Rockai
3fdb45d040 pvscan: Respect lvmetad (global) filter in --cache w/ a device. 2013-07-22 15:05:39 +02:00
Zdenek Kabelac
f1d5f6ae81 lvconvert: drop limit on thin pool conversion 2013-07-22 12:41:22 +02:00
Zdenek Kabelac
c394c2a624 dumpconfig: check conf tree was created
Missing error path.
2013-07-22 12:41:21 +02:00
Alasdair G Kergon
ccc29f17b6 cmdline: support ARG_GROUPABLE in merge_synonym 2013-07-19 20:37:43 +01:00
Alasdair G Kergon
90a09559ed commandline: add prefix aliases for raid options
Accept --raidwritemostly as well as --writemostly etc.
2013-07-19 19:24:54 +01:00
Zdenek Kabelac
ef3a1a0f8a thin: vgsplit and vgmerge spare support
When spliting a VG with spare, update to which VG it will belong.

When merging and both VGs have spare, unmark the smaller one first.
2013-07-18 18:22:44 +02:00
Zdenek Kabelac
aab53f46ee thin: add lvconvert pool metadata spare
Support poolmetadataspare when convering volumes into thin pool.
Same rules applied as with lvcreate.
2013-07-18 18:22:44 +02:00