summaryrefslogtreecommitdiff
path: root/lib/datastruct
Commit message (Collapse)AuthorAgeFilesLines
* cleanup: eliminate unused assignZdenek Kabelac2021-03-111-1/+1
|
* build: Don't generate symlinks in include/ dirJoe Thornber2018-05-142-4/+4
| | | | | | | As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
* datastruct: Add str_list_wipe.Alasdair G Kergon2016-04-292-5/+14
|
* doc: change fsf addressZdenek Kabelac2016-01-214-4/+4
| | | | | Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
* cleanup: drop unneded check for memZdenek Kabelac2015-11-131-2/+2
| | | | Revert missed to drop this extra check.
* str_list: do not support str lists without mempoolsPeter Rajnoha2015-11-112-21/+4
| | | | | Do not support str lists without mempools. Instead, create temporary mempool where necessary (currently only _get_report_options fn).
* cleanup: drop unneeded header fileZdenek Kabelac2015-11-091-2/+0
|
* str_list: add str_list_destroy functionPeter Rajnoha2015-10-302-0/+15
| | | | | | The str_list_destroy function may be called to cleanup memory when the list is not used anymore and the list itself was not allocated from the memory pool.
* str_list: add str_list_to_str and str_to_str_list functionsPeter Rajnoha2015-10-302-0/+89
| | | | | The str_list_to_str and str_to_str_list are helper functions to convert string list to a single string and vice versa.
* str_list: also allow memory allocation without memory poolPeter Rajnoha2015-10-301-2/+4
|
* datastruct: Add str_list_add_list.Alasdair G Kergon2015-03-262-0/+16
|
* cleanup: consolidate lv_layout and lv_role reportingPeter Rajnoha2014-08-252-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes the keyword combinations found in "lv_layout" and "lv_role" much more understandable - there were some ambiguities for some of the combinations which lead to confusion before. Now, the scheme used is: LAYOUTS ("how the LV is laid out"): =================================== [linear] (all segments have number of stripes = 1) [striped] (all segments have number of stripes > 1) [linear,striped] (mixed linear and striped) raid (raid layout always reported together with raid level, raid layout == image + metadata LVs underneath that make up raid LV) [raid,raid1] [raid,raid10] [raid,raid4] [raid,raid5] (exact sublayout not specified during creation - default one used - raid5_ls) [raid,raid5,raid5_ls] [raid,raid5,raid6_rs] [raid,raid5,raid5_la] [raid,raid5,raid5_ra] [raid6,raid] (exact sublayout not specified during creation - default one used - raid6_zr) [raid,raid6,raid6_zr] [raid,raid6,raid6_nc] [raid,raid6,raid6_ns] [mirror] (mirror layout == log + image LVs underneath that make up mirror LV) thin (thin layout always reported together with sublayout) [thin,sparse] (thin layout == allocated out of thin pool) [thin,pool] (thin pool layout == data + metadata volumes underneath that make up thin pool LV, not supposed to be used for direct use!!!) [cache] (cache layout == allocated out of cache pool in conjunction with cache origin) [cache,pool] (cache pool layout == data + metadata volumes underneath that make up cache pool LV, not supposed to be used for direct use!!!) [virtual] (virtual layout == not hitting disk underneath, currently this layout denotes only 'zero' device used for origin,thickorigin role) [unknown] (either error state or missing recognition for such layout) ROLES ("what's the purpose or use of the LV - what is its role"): ================================================================= - each LV has either of these two roles at least: [public] (public LV that users may use freely to write their data to) [public] (public LV that users may use freely to write their data to) [private] (private LV that LVM maintains; not supposed to be directly used by user to write his data to) - and then some special-purpose roles in addition to that: [origin,thickorigin] (origin for thick-style snapshot; "thick" as opposed to "thin") [origin,multithickorigin] (there are more than 2 thick-style snapshots for this origin) [origin,thinorigin] (origin for thin snapshot) [origin,multithinorigin] (there are more than 2 thin snapshots for this origin) [origin,extorigin] (external origin for thin snapshot) [origin,multiextoriginl (there are more than 2 thin snapshots using this external origin) [origin,cacheorigin] (cache origin) [snapshot,thicksnapshot] (thick-style snapshot; "thick" as opposed to "thin") [snapshot,thinsnapshot] (thin-style snapshot) [raid,metadata] (raid metadata LV) [raid,image] (raid image LV) [mirror,image] (mirror image LV) [mirror,log] (mirror log LV) [pvmove] (pvmove LV) [thin,pool,data] (thin pool data LV) [thin,pool,metadata] (thin pool metadata LV) [cache,pool,data] (cache pool data LV) [cache,pool,metadata] (cache pool metadata LV) [pool,spare] (pool spare LV - common role of LV that makes it used for both thin and cache repairs)
* Add lv_layout_and_type fn, lv_layout and lv_type reporting fields.Peter Rajnoha2014-08-152-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lv_layout and lv_type fields together help with LV identification. We can do basic identification using the lv_attr field which provides very condensed view. In contrast to that, the new lv_layout and lv_type fields provide more detialed information on exact layout and type used for LVs. For top-level LVs which are pure types not combined with any other LV types, the lv_layout value is equal to lv_type value. For non-top-level LVs which may be combined with other types, the lv_layout describes the underlying layout used, while the lv_type describes the use/type/usage of the LV. These two new fields are both string lists so selection (-S/--select) criteria can be defined using the list operators easily: [] for strict matching {} for subset matching. For example, let's consider this: $ lvs -a -o name,vg_name,lv_attr,layout,type LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare pool vg twi-a-tz-- pool,thin pool,thin [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tdata_rimage_0] vg iwi-aor--- linear image,raid [pool_tdata_rimage_1] vg iwi-aor--- linear image,raid [pool_tdata_rimage_2] vg iwi-aor--- linear image,raid [pool_tdata_rimage_3] vg iwi-aor--- linear image,raid [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rimage_0] vg iwi-aor--- linear image,raid [pool_tmeta_rimage_1] vg iwi-aor--- linear image,raid [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin thin_vol1 vg Vwi-a-tz-- thin thin thin_vol2 vg Vwi-a-tz-- thin multiple,origin,thin Which is a situation with thin pool, thin volumes and thin snapshots. We can see internal 'pool_tdata' volume that makes up thin pool has actually a level10 raid layout and the internal 'pool_tmeta' has level1 raid layout. Also, we can see that 'thin_snap1' and 'thin_snap2' are both thin snapshots while 'thin_vol1' is thin origin (having multiple snapshots). Such reporting scheme provides much better base for selection criteria in addition to providing more detailed information, for example: $ lvs -a -o name,vg_name,lv_attr,layout,type -S 'type=metadata' LV VG Attr Layout Type [lvol1_pmspare] vg ewi------- linear metadata,pool,spare [pool_tdata_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_1] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_2] vg ewi-aor--- linear metadata,raid [pool_tdata_rmeta_3] vg ewi-aor--- linear metadata,raid [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin [pool_tmeta_rmeta_0] vg ewi-aor--- linear metadata,raid [pool_tmeta_rmeta_1] vg ewi-aor--- linear metadata,raid (selected all LVs which are related to metadata of any type) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={metadata,thin}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs which hold metadata related to thin) lvs -a -o name,vg_name,lv_attr,layout,type -S 'type={thin,snapshot}' LV VG Attr Layout Type thin_snap1 vg Vwi---tz-k thin snapshot,thin thin_snap2 vg Vwi---tz-k thin snapshot,thin (selected all LVs which are thin snapshots) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout=raid' LV VG Attr Layout Type [pool_tdata] vg rwi-aor--- level10,raid data,pool,thin [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid layout, any raid layout) lvs -a -o name,vg_name,lv_attr,layout,type -S 'layout={raid,level1}' LV VG Attr Layout Type [pool_tmeta] vg ewi-aor--- level1,raid metadata,pool,thin (selected all LVs with raid level1 layout exactly) And so on...
* report: select: refactor: move str_list to libdmPeter Rajnoha2014-06-172-32/+6
| | | | | | | | | | The list of strings is used quite frequently and we'd like to reuse this simple structure for report selection support too. Make it part of libdevmapper for general reuse throughout the code. This also simplifies the LVM code a bit since we don't need to include and manage lvm-types.h anymore (the string list was the only structure defined there).
* cleanup: reduce inclusion of unnecessary headersZdenek Kabelac2014-04-181-3/+0
| | | | | Remove those file which are not needed by .c files or already include because the headers already needs them.
* cleanup: do include lvm headers in libdm buildZdenek Kabelac2014-04-081-5/+0
| | | | | Relocate some defines from lvm headers to those few shared between libdm and lib code.
* cleanup: self compilable headersZdenek Kabelac2013-12-122-0/+5
|
* Switch to return voidZdenek Kabelac2012-02-082-8/+5
| | | | List delete cannot fail, so there is no reason to test for error.
* Revert the #include changes. Need to fix this at the #include site for now, andPetr Rockai2011-07-181-1/+0
| | | | eventually refactor the way we structure #includes in the all of the library.
* Add a missing libdevmapper.h #include to lvm-types.h (for dm_list).Petr Rockai2011-07-181-0/+1
|
* Better const cast logicZdenek Kabelac2011-04-081-4/+4
| | | | (although still gcc gives const violation warning)
* Some const cleanupsZdenek Kabelac2010-12-201-1/+1
| | | | Minor const warning fixes and internal API updates.
* Preserve const for char pointerZdenek Kabelac2010-11-112-2/+2
| | | | Keep char pointers 'const' (introduced with cling commit).
* Extend cling allocation policy to recognise PV tags (cling_by_tags).Alasdair Kergon2010-11-092-4/+8
| | | | Add allocation/cling_tag_list to lvm.conf.
* Remove unnecessary / duplicate dm_list macros and functions.Dave Wysochanski2009-11-252-353/+0
| | | | | | | | | These are no longer used by anyone. The dm_list defines are all in libdevmapper.h and libdm/datastruct/list.c contains any function definitions. There is some code in "old-tests" that still use this but this code is not being maintained. Thanks to Zdenek for spotting this.
* Update error return and comments for lvm_list_vg_names/uuids.Dave Wysochanski2009-07-271-2/+4
| | | | | | | | | | | | | | | | | | The two liblvm functions that return a list of vgnames and vguuids use cmd->mem to allocate the list. Make it clear to the caller that this memory will be freed when the LVM handle is freed. Clean up and clarify the return value of the functions. In the case of a memory allocation error, add a couple log_errnos to the internal code, and make it clear that memory allocation returns a NULL pointer. If there are no VGs in the system, the list returned is an empty list. Make a note of the fact that currently we return hidden VG names, how these can be detected (always start with "#"), and that they should not be used. Author: Dave Wysochanski <dwysocha@redhat.com>
* more missing bitsAlasdair Kergon2008-11-041-2/+0
|
* Right, a simple build (without options) is working again.Alasdair Kergon2008-11-035-97/+97
|
* Improve file descriptor leak detection to display likely culprit and filename.Alasdair Kergon2008-08-011-0/+1
|
* make list_move consistent with other list fnsAlasdair Kergon2008-04-102-8/+12
|
* Add list_move() support function for list manipulation.Dave Wysochanski2008-03-261-0/+10
|
* Some whitespace tidy-ups.Alasdair Kergon2008-01-301-1/+1
|
* Use stack return macros throughout.Alasdair Kergon2008-01-302-20/+10
|
* Fix strdup memory leak in str_list_dup().Alasdair Kergon2007-09-171-1/+1
|
* Fix inconsistent licence notices: executables are GPLv2; libraries LGPLv2.1.Alasdair Kergon2007-08-207-22/+22
|
* Add "const" attributes where possible: first cut.Jim Meyering2007-08-076-33/+36
|
* Fix warnings on x86_64 involving ptrdiff_t:Dave Wysochanski2007-04-261-0/+1
| | | | | | config/config.c:493: warning: format '%d' expects type 'int', but argument 5 has type 'long int' Modified original patch from Jim Meyering <jim@meyering.net>
* remove inlinesAlasdair Kergon2006-04-191-0/+136
|
* Check for libsepol.Alasdair Kergon2006-04-192-68/+13
| | | | | | Add some cflow & scope support. Separate out DEFS from CFLAGS. Remove inlines and use unique function names.
* Use hash, bitset, malloc, pool from libdevmapper.Alasdair Kergon2005-10-169-475/+33
|
* Option for bitset memory allocation using malloc as well as pool.Alasdair Kergon2005-09-161-1/+10
|
* Basic support for mirrors.Alasdair Kergon2005-06-011-0/+27
|
* Fix contiguous allocations with linear.Alasdair Kergon2005-05-111-0/+8
|
* %Zu->zuAlasdair Kergon2005-05-091-1/+1
|
* more refinementsAlasdair Kergon2005-04-061-9/+10
|
* Annotate, tidy and extend list.h.Alasdair Kergon2005-04-061-9/+99
|
* Extend hash functions to handle non-null-terminated data.Alasdair Kergon2004-06-182-22/+48
|
* Update copyright notices.Alasdair Kergon2004-03-3010-20/+110
|
* More str_list fns.Alasdair Kergon2004-03-082-0/+41
|
* Don't inline hash _findAlasdair Kergon2004-02-131-1/+1
|
View Lorry Controller Status