summaryrefslogtreecommitdiff
path: root/tools/vgremove.c
Commit message (Collapse)AuthorAgeFilesLines
* vgremove: remove online files in run dirDavid Teigland2022-09-141-0/+3
| | | | | | | | | | | These files are automatically cleared on reboot given that /run is tmpfs, and that remains the primary way of clearing online files. But, if there's extreme use of vgcreate+pvscan+vgremove between reboots, then removing online files in vgremove will limit the number of unused online files using space in /run.
* vgremove: remove forgotten pmspareZdenek Kabelac2021-07-211-0/+4
| | | | | | | | | As pmspare is an invisible LV it's not getting automatically removed since vgremove removes only visible LVs and it depending LVs. If there was no other thin/cache pool volume, such pmspare stayed undeleted and caused command failure. So handle explicitelly such forgotten pmspare and remove it.
* exported vg handlingDavid Teigland2019-06-251-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The exported VG checking/enforcement was scattered and inconsistent. This centralizes it and makes it consistent, following the existing approach for foreign and shared VGs/PVs, which are very similar to exported VGs/PVs. The access policy that now applies to foreign/shared/exported VGs/PVs, is that if a foreign/shared/exported VG/PV is named on the command line (i.e. explicitly requested by the user), and the command is not permitted to operate on it because it is foreign/shared/exported, then an access error is reported and the command exits with an error. But, if the command is processing all VGs/PVs, and happens to come across a foreign/shared/exported VG/PV (that is not explicitly named on the command line), then the command silently skips it and does not produce an error. A command using tags or --select handles inaccessible VGs/PVs the same way as a command processing all VGs/PVs, and will not report/return errors if these inaccessible VGs/PVs exist. The new policy fixes the exit codes on a somewhat random set of commands that previously exited with an error if they were looking at all VGs/PVs and an exported VG existed on the system. There should be no change to which commands are allowed/disallowed on exported VGs/PVs. Certain LV commands (lvs/lvdisplay/lvscan) would previously not display LVs from an exported VG (for unknown reasons). This has not changed. The lvm fullreport command would previously report info about an exported VG but not about the LVs in it. This has changed to include all info from the exported VG.
* move wipe_outdated_pvs to vg_writeDavid Teigland2019-06-071-0/+2
| | | | | | | | | | and implement it based on a device, not based on a pv struct (which is not available when the device is not a part of the vg.) currently only the vgremove command wipes outdated pvs until more advanced recovery is added in a subsequent commit
* locking: unify global lock for flock and lockdDavid Teigland2019-04-291-20/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There have been two file locks used to protect lvm "global state": "ORPHANS" and "GLOBAL". Commands that used the ORPHAN flock in exclusive mode: pvcreate, pvremove, vgcreate, vgextend, vgremove, vgcfgrestore Commands that used the ORPHAN flock in shared mode: vgimportclone, pvs, pvscan, pvresize, pvmove, pvdisplay, pvchange, fullreport Commands that used the GLOBAL flock in exclusive mode: pvchange, pvscan, vgimportclone, vgscan Commands that used the GLOBAL flock in shared mode: pvscan --cache, pvs The ORPHAN lock covers the important cases of serializing the use of orphan PVs. It also partially covers the reporting of orphan PVs (although not correctly as explained below.) The GLOBAL lock doesn't seem to have a clear purpose (it may have eroded over time.) Neither lock correctly protects the VG namespace, or orphan PV properties. To simplify and correct these issues, the two separate flocks are combined into the one GLOBAL flock, and this flock is used from the locking sites that are in place for the lvmlockd global lock. The logic behind the lvmlockd (distributed) global lock is that any command that changes "global state" needs to take the global lock in ex mode. Global state in lvm is: the list of VG names, the set of orphan PVs, and any properties of orphan PVs. Reading this global state can use the global lock in sh mode to ensure it doesn't change while being reported. The locking of global state now looks like: lockd_global() previously named lockd_gl(), acquires the distributed global lock through lvmlockd. This is unchanged. It serializes distributed lvm commands that are changing global state. This is a no-op when lvmlockd is not in use. lockf_global() acquires an flock on a local file. It serializes local lvm commands that are changing global state. lock_global() first calls lockf_global() to acquire the local flock for global state, and if this succeeds, it calls lockd_global() to acquire the distributed lock for global state. Replace instances of lockd_gl() with lock_global(), so that the existing sites for lvmlockd global state locking are now also used for local file locking of global state. Remove the previous file locking calls lock_vol(GLOBAL) and lock_vol(ORPHAN). The following commands which change global state are now serialized with the exclusive global flock: pvchange (of orphan), pvresize (of orphan), pvcreate, pvremove, vgcreate, vgextend, vgremove, vgreduce, vgrename, vgcfgrestore, vgimportclone, vgmerge, vgsplit Commands that use a shared flock to read global state (and will be serialized against the prior list) are those that use process_each functions that are based on processing a list of all VG names, or all PVs. The list of all VGs or all PVs is global state and the shared lock prevents those lists from changing while the command is processing them. The ORPHAN lock previously attempted to produce an accurate listing of orphan PVs, but it was only acquired at the end of the command during the fake vg_read of the fake orphan vg. This is not when orphan PVs were determined; they were determined by elimination beforehand by processing all real VGs, and subtracting the PVs in the real VGs from the list of all PVs that had been identified during the initial scan. This is fixed by holding the single global lock in shared mode while processing all VGs to determine the list of orphan PVs.
* add device hints to reduce scanningDavid Teigland2019-01-151-0/+2
| | | | | | | Save the list of PVs in /run/lvm/hints. These hints are used to reduce scanning in a number of commands to only the PVs on the system, or only the PVs in a requested VG (rather than all devices on the system.)
* Fix use of orphan lock in commandsDavid Teigland2018-06-121-0/+7
| | | | | | | | | | | | vgreduce, vgremove and vgcfgrestore were acquiring the orphan lock in the midst of command processing instead of at the start of the command. (The orphan lock moved to being acquired at the start of the command back when pvcreate/vgcreate/vgextend were reworked based on pvcreate_each_device.) vgsplit also needed a small update to avoid reacquiring a VG lock that it already held (for the new VG name).
* tidy: Add missing underscores to statics.Alasdair G Kergon2017-10-181-4/+4
|
* process_each_lv: add check_single_lv functionDavid Teigland2017-02-131-1/+1
| | | | | | | | | | | | | | | | | The new check_single_lv() function is called prior to the existing process_single_lv(). If the check function returns 0, the LV will not be processed. The check_single_lv function is meant to be a standard method to validate the combination of specific command + specific LV, and decide if the combination is allowed. The check_single function can be used by anything that calls process_each_lv. As commands are migrated to take advantage of command definitions, each command definition gets its own entry point which calls process_each for itself, passing a pair of check_single/process_single functions which can be specific to the narrowly defined command def.
* toollib: make it possible to also process internal VGs, add ↵Peter Rajnoha2016-06-201-1/+1
| | | | | | | | | 'include_internal' switch to process_each_vg fn The lvm fullreport works per VG and as such, the vg, lv, pv, seg and pvseg subreport is done for each VG. However, if the PV is not part of any VG yet, we still want to display pv and pvseg subreports for these "orphan" PVs - so enable this for lvm fullreport's process_each_vg call.
* toollib: add vg name list arg to process_each_vgDavid Teigland2016-05-231-1/+1
|
* doc: change fsf addressZdenek Kabelac2016-01-211-1/+1
| | | | | Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
* vgextend: pass single vgname as process_each_vg argDavid Teigland2015-12-011-1/+1
| | | | | | | | | Pass the single vgname as a new process_each_vg arg instead of setting a cmd flag to tell process_each_vg to take only the first vgname arg from argv. Other commands with different argv formats will be able to use it this way.
* lvmlockd: add full changing of lock typeDavid Teigland2015-08-271-1/+1
| | | | | | | | Remove the existing lock type using the same functions used to remove the lockd components during vgremove. This results in a "clean" VG and lvmlockd state after the vgchange, i.e. no bits left over from previous lock type.
* Add lvmlockddev-dct-lvmlockd-AZDavid Teigland2015-07-021-0/+19
|
* cleanup: tools: "or use -S for selection" --> "or use --select for selection"Peter Rajnoha2015-03-041-1/+1
|
* vgremove: select: direct selection to be done per-VG, not per-LVPeter Rajnoha2015-03-041-1/+15
| | | | | | | | | | | | | | | | | | Though vgremove operates per VG by definition, internally, it actually means iterating over each LV it contains to do the remove. So we need to direct selection a bit in this case so that the selection is done per-VG, not per-LV. That means, use processing handle with void_handle.internal_report_for_select=0 for the process_each_lv_in_vg that is called later in vgremove_single fn. We need to disable internal selection for process_each_lv_in_vg here as selection is already done by process_each_vg which calls vgremove_single. Otherwise selection would be done per-LV and not per-VG as we intend! An intra-release fix for commit 00744b053f395be79ab1cb80fdf7342548aa79e2.
* tools: allow -S|--select for vgremove and lvremovePeter Rajnoha2015-02-101-2/+3
|
* toollib: replace void *handle with struct processing_handle for use in ↵Peter Rajnoha2015-02-101-1/+1
| | | | | | | | | | | | | | | | | | processing functions (process_each_*/process_single_* and related) This patch replaces "void *handle" with "struct processing_handle *handle" in process_each_*, process_single_* and related functions. The struct processing_handle consists of two handles inside now: - the "struct selection_handle *selection_handle" used for applying selection criteria while processing process_each_*, process_single_* and related functions (patches using this logic will follow) - the "void* custom_handle" (this is actually the original handle used before this patch - a pointer to custom data passed into process_each_*, process_single_* and related functions).
* vgremove: Use process_each_lv_in_vg.Alasdair G Kergon2014-10-071-2/+6
|
* vg/lvremove: support --yesZdenek Kabelac2014-10-061-3/+8
| | | | | | Make --yes equivalent to DONT_PROMT (--force). So user could use 'lvremove --yes vg/lvol1' skipping prompt.
* cleanup: introduce return_ECMD_FAILED macroZdenek Kabelac2013-07-011-16/+8
| | | | | | Use shortening macro for common code sequence stack; return ECMD_FAILED;
* Make force_t enum usage obviousZdenek Kabelac2012-02-271-1/+1
|
* Use __attribute__ consistently throughout.Alasdair Kergon2010-07-091-1/+1
|
* Refactor vg_remove_check to place pv removal into separate function.Dave Wysochanski2010-06-301-0/+2
|
* Fix vgremove to allow removal of VG with missing PVs. (2.02.52)Milan Broz2010-06-301-1/+1
|
* Allow vgremove of a VG with PVs missing.Petr Rockai2010-01-081-8/+13
|
* Fix tools to report error when stopped by user.Milan Broz2009-12-031-1/+1
| | | | (And do not produce internal error message.)
* Fix process_each_vg / _process_one_vg when vg_read() returns FAILED_LOCKING.Dave Wysochanski2009-09-151-5/+0
| | | | | | | | | | | | | | Remove the checks for vg_read_error() in most of the tools callback functions and instead make the check in _process_one_vg() more general. In all but vgcfgbackup, we do not want to proceed if we get any error from vg_read(). In vgcfgbackup's case, we may proceed if the backup is to proceed with inconsistent VGs. This is a special case though, and we mark it with the READ_ALLOW_INCONSISTENT flag passed to process_each_vg (and subsequently to _process_one_vg). NOTE: More cleanup is needed in the vg_read_error() path cases. This patch is a start.
* Add lots of missing stack debug messages to tools.Alasdair Kergon2009-09-141-5/+15
| | | | | Make readonly locking available as locking type 4. Fix readonly locking to permit writeable global locks (for vgscan). (2.02.49)
* Split vg_remove_single into 2 functions - the second part commits to disk.Dave Wysochanski2009-09-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | Split vg_remove_single into vg_remove_check (mandatory checks before vgremove) and vg_remove (do actual remove by committing to disk). In liblvm, we'd like to provide an consistent API that allows multiple changes in memory, then let lvm_vg_write() control the commit to disk. In some cases (for example, lvresize calls fsadm) this may not be possible. However, since we are using an object model and dividing things into small operations, the most logical model seems to be the lvm_vg_write model, and handling the special cases as they arrive. So as best as possible we move towards this end. A possible optimization would be to consolidate vg_remove (committing) code with vgreduce code. A second possible optimization is making vgreduce of the last device equivalent to vgremove. Today, lvm_vg_reduce fails if vgreduce is called with the last device, but from an object model perspective we could view this as equivalent to vgremove and allow it. My gut feel is we do not want to do this though. Author: Dave Wysochanski <dwysocha@redhat.com>
* Fix vgck and vgremove segfault if non-existent vg given.Dave Wysochanski2009-07-141-0/+3
| | | | Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Move orphan lock inside vg_remove_single.Dave Wysochanski2009-07-101-7/+0
| | | | | | | | | | | | | | Move the vg orphan lock inside vg_remove_single, now a complete liblvm function. Note that this changes the order of the locks - originally VG_ORPHAN was obtained first, then the vgname lock. With the current policy of non-blocking second locks, this could mean we get a failure obtaining the orphan lock. In the case of a vg with lvs being removed, this could result in the lvs being removed but not the vg. Such a scenario could have happened prior though with a different failure. Other tools were examined for side-effects, and no major problems were noted. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Remove force parameter from vg_remove_single, now the liblvm function.Dave Wysochanski2009-07-101-1/+23
| | | | | | | | | | | | | | | | | | | Move check for active LVs outside of library function. The vgremove liblvm function function will fail if there are active LVs. It will be the application's responsibility to check this condition and remove the LVs individually before calling vgremove. Note also that we've duplicated the EXPORTED_VG check in vgremove_single (tools) and vg_remove_single (library). Duplication seemed the only option here since we don't want to do the automatic removal of LVs (in the tools) if the vg is exported, and we still need to protect the library call from removal if the vg is exported. We still need to deal with the ORPHAN lock but vg_remove_single is now very close to our liblvm function. TODO: Refactor lvremove in a similar way. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Remove unnecessary parameters from vg_remove_single().Dave Wysochanski2009-07-101-2/+1
| | | | | | | Use vg_t instead of struct volume_group. Should be no functional change. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Remove unneeded LOCK_NONBLOCKING from vg_read() API.Dave Wysochanski2009-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Remove unneeded LOCK_NONBLOCKING from vg_read() API and tools that use it. We no longer need this flag anywhere since we now automatically set LCK_NONBLOCK inside lock_vol() if vgs_locked(). For further details, see: commit d52b3fd3fe2006e2d13e42f8518b6512bff03710 Author: Dave Wysochanski <dwysocha@redhat.com> Date: Wed May 13 13:02:52 2009 +0000 Remove NON_BLOCKING lock flag from tools and set a policy to auto-set. As a simplification to the tools and further liblvm, this patch pushes the setting of NON_BLOCKING lock flag inside the lock_vol() call. The policy we set is if any existing VGs are currently locked, we set the NON_BLOCKING flag. At some point it may make sense to add this flag back if we get an RFE from a liblvm user, but for now let's keep it as simple as possible. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Rework the toollib interface (process_each_*) on top of new vg_read.Dave Wysochanski2009-07-011-6/+4
| | | | | | | | | Sun May 3 12:32:30 CEST 2009 Petr Rockai <me@mornfall.net> * Rework the toollib interface (process_each_*) on top of new vg_read. Rebased 6/26/09 by Dave W. - Add skipping message to process_each_lv - Remove inconsistent_t.
* Fix double releasing of vg when repairing of vg is requested.Milan Broz2009-06-051-2/+4
| | | | | | | | | | | | | | | | | | | | Several commands calls process_each_vg() and in provided callback it explicitly recovers VG if inconsistent. (vgchange, vgconvert, vgscan) It means that old VG is released and reread but the function above (process_one_vg) tries to unlock and release old VG. Patch moves the repair logic into _process_one_vg() function. It always tries to read vg (even inconsistent) and then decides what to do according new defined parameter. Also patch unifies inconsistent error messages. The only slight change if for vgremove command, where it now tries to repair VG before it removes if force arg is given. (It works similar way before, just the order of operation changed).
* Remove NON_BLOCKING lock flag from tools and set a policy to auto-set.Dave Wysochanski2009-05-131-2/+2
| | | | | | | | | As a simplification to the tools and further liblvm, this patch pushes the setting of NON_BLOCKING lock flag inside the lock_vol() call. The policy we set is if any existing VGs are currently locked, we set the NON_BLOCKING flag. Should be no functional change.
* Some whitespace tidy-ups.Alasdair Kergon2008-01-301-2/+2
|
* Fix orphan-related locking in pvdisplay and pvs.Alasdair Kergon2007-11-021-2/+2
| | | | | | | | Fix missing VG unlocks in some pvchange error paths. Add some missing validation of VG names. Rename validate_vg_name() to validate_new_vg_name(). Change orphan lock to VG_ORPHANS. Change format1 to use ORPHAN as orphan VG name.
* Move guts of vgremove into lvm library.Dave Wysochanski2007-08-211-65/+0
| | | | Include archiver.h in metadata.c as a result of prior move.
* Prepare to move guts of vgremove into lvm library.Dave Wysochanski2007-08-211-12/+22
| | | | Fixup force_t.
* Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.Alasdair Kergon2007-08-201-3/+3
|
* Convert vg->status checks to use vg_check_status function.\nRename ↵Dave Wysochanski2007-06-191-4/+2
| | | | status_flags to status in vg_check_status.
* Remove get_ prefix from get_pv_* functionsDave Wysochanski2007-06-151-4/+4
|
* Convert pv->dev to get_pv_devDave Wysochanski2007-06-131-4/+4
|
* Fix vgremove to require at least one vg argument.Milan Broz2007-03-151-0/+5
|
* Make SIZE_SHORT the default for display_size().Alasdair Kergon2006-05-091-1/+1
| | | | | | | Fix some memory leaks in error paths found by coverity. Use C99 struct initialisers. Move DEFS into configure.h. Clean-ups to remove miscellaneous compiler warnings.
* Use ORPHAN lock definition throughout.Alasdair Kergon2005-10-031-2/+2
|
View Lorry Controller Status