summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* vg_read: skip repair and wipe for foreign and shared VGsdev-dct-lvmetad8David Teigland2015-10-281-0/+36
| | | | | | | | | | | | | | | | 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.
* lvmetad: refresh content at command startDavid Teigland2015-10-287-14/+258
| | | | | | | | | | | | | | | | | 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.
* lvmcache: change log_verbose to log_warnDavid Teigland2015-10-281-3/+3
|
* pvscan: --cache should scan all devicesDavid Teigland2015-10-282-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* lvmetad: warn about all duplicate PVs in commandDavid Teigland2015-10-281-3/+8
| | | | | | | 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.
* lvmetad: rewrite update codeDavid Teigland2015-10-281-280/+1489
| | | | | | | | | | | | | | | | | | | 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.
* pvs: don't treat duplicate PVs as missedDavid Teigland2015-10-271-3/+21
| | | | | | | | | | 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.
* vgs, lvs: ignore error if VG is removedDavid Teigland2015-10-271-10/+16
| | | | | | | | | 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.
* device: Tidy DASD CDL format detection code.Alasdair G Kergon2015-10-271-24/+61
|
* tests: using matching typeZdenek Kabelac2015-10-271-1/+1
| | | | Compare time_t.
* tests: use more SKIPZdenek Kabelac2015-10-27171-336/+333
| | | | Speed-up check_lvmpolld.
* tests: avoid reading utils when skippingZdenek Kabelac2015-10-271-9/+17
| | | | Save even more CPU/time and avoid reading utils, when skipping test.
* cleanup: snapshots of snapshots messageMarian Csontos2015-10-272-2/+2
| | | | No plans to support thick snapshost of snapshots.
* pvcreate: don't support unpartitioned DASD devices with CDL formattedLidong Zhong2015-10-275-1/+78
| | | | | | | | | 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>
* dmeventd: event string parser handles empty fieldZdenek Kabelac2015-10-272-17/+32
| | | | | | | | | | | | | | 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.
* tests: use skip flagsZdenek Kabelac2015-10-2724-60/+65
| | | | corrected usage of skip flags.
* tests: support skip flagsZdenek Kabelac2015-10-261-4/+9
|
* tests: extend timer for 4 hoursZdenek Kabelac2015-10-262-4/+7
| | | | | | Extend max time for test suite to 4 hours. Also replace some 'non-ascii' chars from source files and keep them plain ascii.
* thin: limit no-flush using only for thin-poolZdenek Kabelac2015-10-262-1/+8
| | | | | | | 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.
* dmevent: fix referencingZdenek Kabelac2015-10-261-1/+0
| | | | Plugin increments DSO refcounter in _alloc_thread_status().
* toollib: fix wrong paren placementDavid Teigland2015-10-261-1/+1
|
* pvs: fix missing PVs when VG is removedDavid Teigland2015-10-261-9/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* tests: snapshot now respects thresholdZdenek Kabelac2015-10-261-3/+3
|
* libdm: enable no_flush for driver version > 11Zdenek Kabelac2015-10-261-2/+7
| | | | | It appears the driver version 11 has troubles with usage of no_flush So require at least version 12.
* dev_manager: no flush for extensionZdenek Kabelac2015-10-252-1/+2
| | | | | | | | | 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.
* dev_manager: enabled no_flush for suspendZdenek Kabelac2015-10-252-1/+2
| | | | | | | | | | | | | | | | | | | 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.
* libdm: dm_tree_node_size_changed recognizes reductionZdenek Kabelac2015-10-255-4/+29
| | | | | | | | | | | | | | | | | 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.
* lv_manip: ensure it will fit bellow thresholdZdenek Kabelac2015-10-252-12/+26
| | | | | | | | | 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.
* thin: fix percentage compareZdenek Kabelac2015-10-252-2/+3
| | | | | | | | | | 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).
* vg_read: remove unused inconsistent checkDavid Teigland2015-10-231-6/+0
| | | | | | | | 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.
* vgextend: fix use of the wrong flagDavid Teigland2015-10-233-3/+3
| | | | | | | | | | | 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.)
* vg_read: sometimes ignore read errorsDavid Teigland2015-10-233-29/+56
| | | | | | | | | | | | | | | | | | | | | Running "vgremove -f VG & pvs" results in the pvs command reporting that the VG is not found or is inconsistent. If the VG is gone or being removed, the pvs command should just skip it and not print errors about it. "Not found" is because the pvs command created the list of VGs to process, including VG, then vgremove removed the VG, then the pvs command came to to read the VG to process it and did not find it. An "inconsistent" error could be reported if vgremove had only partially completed removing VG when pvs did vg_read on the VG to process it, causing pvs to find the VG in a partially-removed state. This fix adds a flag that pvs uses to ignore a VG that can't be read or is inconsistent.
* thin: Fix typo in policy threshold message.Alasdair G Kergon2015-10-231-2/+2
|
* lvmcache: update cached info properly when moving from VG to orphan while ↵Peter Rajnoha2015-10-232-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lvmetad is used When lvmetad is used and lvmcache update function (lvmcache_update_vgname_and_id) was called to update existing lvmcache records, a condition was met which made to retun from the update function immediately, effectively making it NOOP. It seems there's no reason for such condition and lvmcache should be update appropriately even when lvmetad used as lvmcache may be reused, most notably in lvm shell. It's possible this is a remnant of the lvmetad development code which didn't get removed for some reason and the bug didn't get spotted because lvm shell is not used often (the condition dates back to 2012 or so). Example, lvmetad and lvm shell used: lvm> pvs PV VG Fmt Attr PSize PFree /dev/sda vg lvm2 a-- 124.00m 124.00m Before this patch: ================== lvm> vgremove vg Volume group "vg" successfully removed lvm> pvs With this patch applied: ======================== lvm> vgremove vg Volume group "vg" successfully removed lvm> pvs PV VG Fmt Attr PSize PFree /dev/sda lvm2 --- 128.00m 128.00m
* pvremove: make sure even invalid info is removed from lvmcache on pvremovePeter Rajnoha2015-10-232-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lvmcache info might be resued, most notably in lvm shell. We need to be sure that even lvmcache_info marked as invalid is removed from the lvmcache so it does not confuse any subsequent code/commands executed later on. Problematic example with the lvm shell: lvm> pvs PV VG Fmt Attr PSize PFree /dev/sda lvm2 --- 128.00m 128.00m Before this patch (/dev/sda still displayed in a way): ====================================================== lvm> pvremove /dev/sda Labels on physical volume "/dev/sda" successfully wiped (without lvmetad) lvm> pvs No physical volume label read from /dev/sda (with lvmetad) lvm> pvs PV VG Fmt Attr PSize PFree /dev/sda lvm2 --- 128.00m 128.00m With this patch applied: ======================== lvm> pvremove /dev/sda Labels on physical volume "/dev/sda" successfully wiped (without lvmetad) lvm> pvs (with lvmetad) lvm> pvs
* cleanup: drop debugZdenek Kabelac2015-10-231-1/+0
|
* cleanup: fix gcc compile with older pthreadZdenek Kabelac2015-10-231-0/+3
| | | | | | | | | | Older pthread library was missing 'trick' in pthread_cleanup_pop() which lead to compilation error: error: label at end of compound statement Use explicit ';' to fix it.
* cleanup: gcc warning for old-styleZdenek Kabelac2015-10-231-1/+1
|
* tools: update for lvm2_disable_dmeventd_monitoringZdenek Kabelac2015-10-233-4/+12
| | | | | | | | | | | | | | | Make lvm2_disable_dmeventd_monitoring() more explicit. As memlock_inc_daemon() is also used by clvmd, which does changes dmeventd and suspend ignore state at some stages - make updates of these 2 variable tied to the call of lvm2_disable_dmeventd_monitoring(). Once this call is made dmeventd monitoring and suspended devices are ignored. TODO: all lvm-global settings should really be moved to command context.
* dmeventd: ensure filter is emptyZdenek Kabelac2015-10-231-0/+1
| | | | | | On some error path we could have left filter set to some value. Not a big issue - but lets make reporting correct as soon as we can.
* dmeventd: debug error pathsZdenek Kabelac2015-10-231-4/+9
|
* tests: enable raid test on 4.3Zdenek Kabelac2015-10-221-2/+1
| | | | | | | With kernel -rc6 it's passing our raid tests again - so enable it in tests. Note: related only to Fedora rawhide kernels...
* cleanup: indentsZdenek Kabelac2015-10-223-7/+7
|
* cleanup: drop uneeded header fileZdenek Kabelac2015-10-221-2/+0
|
* cleanup: easier to read codeZdenek Kabelac2015-10-221-10/+4
| | | | Avoid using #ifdef code and use 'cmd' instead of 'die'.
* cleanup: declare vars before codeZdenek Kabelac2015-10-221-6/+3
|
* dmeventd: exit on idleZdenek Kabelac2015-10-222-8/+28
| | | | | | | | | | | | Implementing exit when 'dmeventd' is idle. Default idle timeout set to 1 hour - after this time period dmeventd will cleanly exit. On systems with 'systemd' - service is automatically started with next contact on dmeventd communication socket/fifo. On other systems - new dmeventd starts again when lvm2 command detects its missing and monitoring is needed.
* dmeventd: debug signalsZdenek Kabelac2015-10-221-0/+20
|
* dmeventd: snapshot plugin unmonitorZdenek Kabelac2015-10-221-0/+10
| | | | | Send signal to itself to mark plugin as 'finished' as the watching rule is no longer usable.
* dmeventd: handle signal from pluginZdenek Kabelac2015-10-222-1/+13
| | | | | | | Add support to unmonitor device when monitor recognizes there is nothing to monitor anymore. TODO: possibly API change with return value could be also used.
View Lorry Controller Status