| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reading a foreign VG we cannot write it, since
it belongs to another host. When reading a shared VG
we cannot write it because we may not have an ex lock.
(Or we may be reading the shared VG while not using
lvmlockd in which case it's like reading a foreign VG.)
Add the same checks for wiping outdated PVs. We may
read a foreign or shared VG, or see the PVs, while
another host is part way through writing a new version
of the VG to the PVs. This might cause us to think
some of the PVs are outdated. We do not want to
write another host's PVs, especially when we may
wrongly conclude they are outdated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the start of the command, check if the lvmetad
content needs updating (token not matching), and
if so do the scan and update it. This gets the
updating done right at the beginning, before
command processing is started. The early scan
already exists for the foreign VGs case, so this
is added to it.
Previously, the command would be part way through
its own processing before discovering via lvmetad_send
that lvmetad needed updating. It's not good to
interrupt a command, insert a 'pvscan --cache', then
continue on with the original command. The pvscan
is likely to interfere with the original command.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running pvscan --cache, the intention is to scan
all devices, i.e. the equivalent of running
'pvscan --cache dev' for each device. But, some devices
holding duplicate PVs were being skipped, and lvmetad
was not being told about them.
This was a side effect of the fact that the lvmcache
layer is used internally during scanning (it's used
to transfer info between the different stages of the
command: label reading, vg reading, sending the vg.)
An unwanted side effect of using lvmcache is that it
eliminates duplicate PVs if it sees them. This
prevented the command from sending some duplicate PVs
to lvmetad (when the first duplicate was preferred
over the second.)
The fix is to drop the lvmcache state between scanning
each PV. There is no need to keep any cache state between
each PV being scanned (there's nothing being reused), and
the unneeded state is causing lvmcache to eliminate
duplicates which is harmful for pvscan --cache.
Also, remove clvm locking from pvscan_lvmetad. This is
not needed since lvmetad cannot be used with clvm. It
was interfering with clearing the cache.
|
| |
|
|
|
|
|
| |
When the command gets a list of alternate devices
from lvmetad, warn about them all directly. This
is not the same as the warnings when adding lvmcache,
which are related to which duplicate is preferred.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
update_metadata and pv_found update the cached metadata;
rewrite both of these to improve the code, make it much
more clear what they do, more thoroughly cover possible
combinations/transitions, add more error checking and
handling, add comments.
The state and content of the cache (hash tables) does not
change (apart from things that didn't work before), and the
transfers to/from commands do not change.
The implementation and organization of the code making
the state changes does change significantly.
One detail related to the content of the cache does change:
different hash tables do not reference the same memory any more;
the target values in each hash table are allocated and freed
individually.
|
| | |
|
| |
|
|
|
|
|
|
| |
When checking minimum mda size, make sure the mda_size after alignment
and calculation is more than 0 - if there's no place for an MDA at the
end of the disk, the _text_pv_add_metadata_area does not try to add it
there and it returns (because we already have the MDA at the start of
the disk at least).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Actually, we don't need extra condition as introduced in commit
00348c0a630a7e5578edf48052ec695b15de752f. We should fix the last
condition:
(mdac->rlocn.size >= mdah->size)
...which should be:
(MDA_HEADER_SIZE + (rlocn ? rlocn->size : 0) + mdac->rlocn.size >= mdah->size))
Where the "mdac" is new metadata, the "rlocn" is old metadata.
So the main problem with the previous condition was that it
didn't count in MDA_HEADER_SIZE properly (and possible existing
metadata - the "rlocn"). This could have caused the error state
where metadata in ring buffer overlap to not be hit.
Replace the new condition introduced in 00348c0a630a7e5578edf48052ec695b15de752f
with the improved one for the condition that existed there
already but it was just incomplete.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're already checking whether old and new meta do not overlap in
ring buffer (as we need to keep both old and new meta during vg_write
up until vg_commit).
We also need to check whether the new metadata do not overlap
themselves in case we don't have old metadata yet (...because
we're in vgcreate). This could happen if we're creating a VG so
that the very first metadata written are long enough that it wraps
themselves in metadata ring buffer.
Although we limited the minimum metadata area size better with the
previous commit ccb8da404d00288b7d49c7a28006ec5d4687bb55 which
makes the initial VG metadata overlap in ring buffer to be less
probable, the risk of hitting this overlap condition is still there
if we still manage to generate big enough metadata somehow.
For example, users can provide many and/or long VG tags during vgcreate
so that the VG metadata is long enough to start to wrap in the ring
buffer again...
|
| | |
|
| |
|
|
|
|
|
|
| |
Drop already tested 'threshold & create' which is in
lvextend-thin-full.sh
Count with now match faster 'dmeventd' wakeup on watermark
as it's now nearly instant after crossing threshold value.
|
| | |
|
| |
|
|
|
|
| |
If the underlaying device has actually bigger read-ahead settings,
let it pass.
But anyway switch to 512 strip-size to get really high R-A sector count.
|
| | |
|
| |
|
|
| |
lvmetad does not support lvm1 - so expect failure.
|
| |
|
|
|
| |
Drop 'WARNING' from error message.
It's plain error message leading to command failure.
|
| |
|
|
|
|
|
| |
This option could never have been printed in lvm2 metadata, so it could
be safely removed as it could have been set only as 0.
These configurable setting is supported via metadata profile.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Now with correctly functioning dmeventd enable usage of
low_water_mark for faster reaction on pool's threshold.
When user select e.g. 80% as a threshold value,
dmeventd doesn't need to wait 10 seconds till monitoring
timer expires, but nearly instantly resizes thin-pool
to fit bellow threshold.
|
| |
|
|
|
|
| |
If plugin's lvm command execution fails too often (>10 times),
there is no point to torture system more then necessary, just log
and drop monitoring in this case.
|
| |
|
|
|
|
| |
size vs. PV mda size
The message needs refinement - it's not correct in all situations.
|
| |
|
|
|
|
|
|
|
|
| |
The recent addition to check for PVs that were
missed during the first iteration of processing
was unintentionally catching duplicate PVs because
duplicates were not removed from the all_devices
list when the primary dev was processed.
Also change a message from warn back to verbose.
|
| |
|
|
|
|
|
|
|
| |
If a VG is removed between the time that 'vgs'
or 'lvs' (with no args) creates the list of VGs
and the time that it reads the VG to process it,
then ignore the removed VG; don't report an error
that it could not be found, since it wasn't named
by the command.
|
| | |
|
| |
|
|
| |
Compare time_t.
|
| |
|
|
| |
Speed-up check_lvmpolld.
|
| |
|
|
| |
Save even more CPU/time and avoid reading utils, when skipping test.
|
| |
|
|
| |
No plans to support thick snapshost of snapshots.
|
| |
|
|
|
|
|
|
|
| |
The former patch(dab3ebce4c7) is a little bit strict. For example, it is
OK to create PV on unpartitioned DASD devices with LDL formatted. So
after lvm version containing the patch, LVs created on those devices
could not be found.
Signed-off-by: Lidong Zhong <lzhong@suse.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve event string parser to avoid unneeded alloc+free.
Daemon talk function uses '-' to mark NULL/missing field.
So restore the NULL pointer back on parser.
This should have made old tools like 'dmevent_tool' work again.
As now 'uuid' or 'dso' could become NULL and then be
properly used in _want_registered_device() function.
Since lvm2 always fill these parameters, this change should
have no effect on lvm2.
|
| |
|
|
| |
corrected usage of skip flags.
|
| | |
|
| |
|
|
|
|
| |
Extend max time for test suite to 4 hours.
Also replace some 'non-ascii' chars from source files
and keep them plain ascii.
|
| |
|
|
|
|
|
| |
For this release keep usage of 'noflush' only for thin-volume/pool.
For rest of keep - keep usage of 'noflush' flag purely for
non-resized mirrors.
|
| |
|
|
| |
Plugin increments DSO refcounter in _alloc_thread_status().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PVs could be missing from the 'pvs' output if
their VG was removed at the same time that the
'pvs' command was run. To fix this:
1. If a VG is not found when processed, don't
silently skip the PVs in it, as is done when
the "skip" variable is set.
2. Repeat the VG search if some PVs are not
found on the first search through all VGs.
The second search uses a specific list of
PVs that were missed the first time.
testing:
/dev/sdb is a PV
/dev/sdd is a PV
/dev/sdg is not a PV
each test begins with:
vgcreate test /dev/sdb /dev/sdd
variations to test:
vgremove -f test & pvs
vgremove -f test & pvs -a
vgremove -f test & pvs /dev/sdb /dev/sdd
vgremove -f test & pvs /dev/sdg
vgremove -f test & pvs /dev/sdb /dev/sdg
The pvs command should always display /dev/sdb
and /dev/sdd, either as a part of VG test or not.
The pvs command should always print an error
indicating that /dev/sdg could not be found.
|
| | |
|
| |
|
|
|
| |
It appears the driver version 11 has troubles with usage of no_flush
So require at least version 12.
|
| |
|
|
|
|
|
|
|
| |
Recognize the target only 'extends' and do not enforce
'flush' in this case. Only the size reduction
still requires flush (so disables usage of no_flush flag).
If some other targets do require flush before suspend,
they have to explicitly ask for it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the activation code tries to evaluate which target
really needs flush with suspend and which may go without flush,
it has stayed effectively disabled by original commit:
33f732c5e9493cda4b161a18b3d53885d207e3b8 since here
it only allows to pass non-pvmoving 'mirrors'.
So remove check for mirror LV type and only disable
no_flush for 'pvmove'..
TODO: Looking into history - it also seemed like raid target
would have always required flushing but it's been later
removed without clean explanation.
If some more targets really do need 'no_flush' it should
been handle at their 'level' - since we now stack multiple
targets over itself.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add more functionality to size_changed function.
While 'existing' API only detected 0 for
unchanged, and !0 for changed,
new improved API will also detected if the
size has only went bigger - or there was
size reduction.
Function work for the whole dm-tree - so
no change is size is always 0.
only size extension 1.
and if some size reduction is there - returns -1.
This result can be used for better evaluation
whether we need to flush before suspend.
|
| |
|
|
|
|
|
|
|
| |
Use single code to evaluate if the percentage value has
crossed threshold.
Recalculate amount value to always fit bellow
threshold so there are not need any extra reiterations
to reach this state in case policy amount is too small.
|
| |
|
|
|
|
|
|
|
|
| |
Since plugin's percentage compare has been fixed,
it's now revealed wrong compare here.
The logic for threshold is - to allow to go as high
as given value e.g. 80% - so if pool is exactlu 80%
full it's still allowed to use it (dmeventd will not
resize it).
|
| |
|
|
|
|
|
|
| |
Commit 1a74171ca5682a684d0e05c6090c3d33cab8795b added
a check to ignore a VG that was FAILED_INCONSISTENT
if the command doesn't care if the VG is not found.
Remove that check because that case is never reached
by the current code.
|
| |
|
|
|
|
|
|
|
|
|
| |
The ONE_VGNAME_ARG was being passed and tested as
vg_read() flag but it's a cmd struct flag.
(It affects command arg processing in toollib,
not vg_read behavior. Flags related to command
processing are generally cmd struct flags, while
vg_read arg flags are generally related to vg_read
behavior.)
|
