summaryrefslogtreecommitdiff
path: root/WHATS_NEW
Commit message (Collapse)AuthorAgeFilesLines
* post-releaseMarian Csontos2023-04-211-0/+3
|
* pre-releasev2_03_21Marian Csontos2023-04-211-1/+2
|
* WHATS_NEW: updateZdenek Kabelac2023-04-061-0/+2
|
* post-releaseMarian Csontos2023-03-211-0/+3
|
* pre-releasev2_03_20Marian Csontos2023-03-211-2/+2
|
* toollib: fix segfault if using -S|--select with log/report_command_log=1 settingPeter Rajnoha2023-03-071-0/+1
| | | | | | | | | | | | | | | | | | | When we are using -S|--select for non-reporting tools while using command log reporting (log/report_command_log=1 setting), we need to create an internal processing handle to handle the selection itself. In this case, the internal processing handle to execute the selection (to process the -S|--select) has a parent handle (that is processing the actual non-reporting command). When this parent handle exists, we can't destroy the command log report in destroy_processing_handle as there's still the parent processing to finish. The parent processing may still generate logs which need to be reported in the command log report. If the command log report was destroyed prematurely together with destroying the internal processing handle for -S|--select, then any subsequent log request from processing the actual command (and hence an attermpt to access the command log report) ended up with a segfault. See also: https://bugzilla.redhat.com/show_bug.cgi?id=2175220
* WHATS_NEW: updatesZdenek Kabelac2023-02-231-0/+2
|
* post-releaseMarian Csontos2023-02-211-0/+3
|
* pre-releasev2_03_19Marian Csontos2023-02-211-2/+2
|
* WHATS_NEW: updateZdenek Kabelac2023-02-101-0/+2
|
* udev: don't reset SYSTEMD_READY in udev for PVs on MD and loopPeter Rajnoha2023-02-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Since 67722b312390cdab29c076c912e14bd739c5c0f6, we have a new mechanism to run the autoactivation from udev. With this change, we also replaced the way the LVM autoactivation service is instantiatiated - instead of setting the SYSTEM_WANTS udev variable (which systemd read and then instantiated the service), we're now directly instantiating the transient 'lvm-activate-<vgname>' service by calling systemd-run. As such, we don't need to bother with setting the SYSTEMD_READY variable for foreign devices anymore (in this case, MD and loop devices on top of which there's a PV). Before, we set the SYSTEMD_READY variable to make sure that the SYSTEMD_WANTS is applied correctly - the service instantiation was edge-triggered by flipping the SYSTEMD_READY from 0 to 1 and at the same time having the SYSTEMD_WANTS variable set to the service name to instantiate. We're using systemd-run now so this condition does not apply anymore. Also, it was not completely correct to set SYSTEMD_READY for foreign devices because there might be cases where this could cause issues, see also https://github.com/lvmteam/lvm2/issues/94.
* device_mapper: reactivate siblings for snapshotZdenek Kabelac2023-02-011-0/+1
| | | | | | | | | When activating origin and its thick snapshots, ensure the origin's LV udev processing is finished first and after this reactivate its snapshot so the udev can scan them afterwards. This should fix the problems for users using UUID of such device in their fstab and occasionaly mounted snapshot instead of origin LV.
* vdo: fix and enhance vdo constain checkingZdenek Kabelac2023-01-161-0/+1
| | | | | | | | Enhance checking vdo constains so it also handles changes of active VDO LVs where only added difference is considered now. For this also the reported informational message about used memory was improved to only list consuming RAM blocks.
* fix typolilinjie2023-01-111-1/+1
| | | | | Signed-off-by: lilinjie <lilinjie@uniontech.com> (cherry picked from commit 81b1f5bc3bac0e2e9099b67162da7d1a4995c5f4)
* post-releaseMarian Csontos2023-01-031-1/+4
|
* pre-releaseMarian Csontos2022-12-221-1/+1
|
* WHATS_NEW: updatev2_03_18Marian Csontos2022-12-221-0/+4
|
* post-releaseMarian Csontos2022-11-101-0/+3
|
* pre-releasev2_03_17Marian Csontos2022-11-101-2/+5
|
* toollib: do not process just created historical LVPeter Rajnoha2022-10-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When executing process_each_lv_in_vg, we process live LVs first and after that, we process any historical LVs. In case we have just removed an LV, which also means we have just made it "historical" and so it appears as fresh item in vg->historical_lvs list, we have to skip it when we get to processing historical LVs inside the same process_each_lv_in_vg call. The simplest approach here, without introducing another LV list, is to simply mark such historical LVs as "fresh" directly in struct historical_logical_volume when we have just removed the original LV and created the historical LV for it. Then, we just need to check the flag when processing historical LVs and skip it if it is "fresh". When we read historical LVs out of metadata, they are marked as "not fresh" and so they can be processed as usual. This was mainly an issue in conjuction with -S|--select use: # lvmconfig --type diff metadata { record_lvs_history=1 } (In this example, a thin pool with lvol1 thin LV and lvol2 and lvol3 snapshots.) # lvs -H vg -o name,pool_lv,full_ancestors,full_descendants LV Pool FAncestors FDescendants lvol1 pool lvol2,lvol3 lvol2 pool lvol1 lvol3 lvol3 pool lvol2,lvol1 pool # lvremove -S 'name=lvol2' Logical volume "lvol2" successfully removed. Historical logical volume "lvol2" successfully removed. ...here, the historical LV lvol2 should not have been removed because we have just removed its original non-historical lvol2 and the fresh historical lvol2 must not be included in the same processing spree.
* report: fix lv_active column type from STR to BINPeter Rajnoha2022-09-061-0/+1
| | | | | | | | Fix lv_active to be of BIN type instead of STR. This allows lv_active to follow the report/binary_values_as_numeric setting as well as --binary cmd line switch. Also, it makes it possible to use -S|--select with either textual or numeric representation of the value, like 'lvs -S active=active' but also 'lvs -S active=1'.
* mm: use mallinfo2 when availableZdenek Kabelac2022-08-301-0/+1
| | | | | Switch to mallinfo2() from a deprecated mallinfo() glibc call since struct size members where to small for 64b CPUs.
* args: add ARG_NONINTERACTIVE for cmds not supported in lvm shellPeter Rajnoha2022-08-261-0/+1
| | | | | | | | | | | Certain args can't be used in lvm shell ("interactive mode") because they are not supported there. Add ARG_NONINTERACTIVE flag to mark such args and error out if we're in interactive mode and at the same time we detect use of such argument. Currently, this is the case for --reportformat arg - we don't support changing the format per command in lvm shell. The whole shell is running under a reportformat chosen at shell's start.
* shell: add pre-cmd log report object type and enable lastlog for itPeter Rajnoha2022-08-221-0/+1
| | | | | | | If we failed or logged anything before we actually execute given command in lvm shell, we couldn't report the log using lastlog command after. This patch adds specific 'pre-cmd' log report object type to identify such log messages and enables lastlog to report even this log.
* vdo: extend volume and pool without flushZdenek Kabelac2022-08-191-0/+1
| | | | | | | | | | | | When the volume size is extended, there is no need to flush IO operations (nothing can be targeting new space yet). VDO target is supported as target that can safely work with this condition. Such support is also needed, when extending VDOPOOL size while the pool is reaching its capacity - since this allows to continue working without reaching 'out-of-space' condition due to flushing of all in flight IO.
* lvmconfig: add --valuesonly optionPeter Rajnoha2022-08-171-0/+1
| | | | | | | | | | | | | | | | | | | | | The new --valuesonly option causes the lvmconfig output to contain only values without keys for each config node. This is practical mainly in case where we use lvmconfig in scripts and we want to assign the value to a different custom key or simply output the value itself without the key. For example: # lvmconfig --type full activation/raid_fault_policy raid_fault_policy="warn" # lvmconfig --type full activation/raid_fault_policy --valuesonly "warn" # my_var=$(lvmconfig --type full activation/raid_fault_policy --valuesonly) # echo $my_var "warn"
* autoreconf: support newer archsZdenek Kabelac2022-08-151-0/+1
| | | | | | | | | | | Update to more recent version of configure script to support more new architecture types like RISCV64. Tools in use ATM: autoconf-2.71-3.fc37.noarch autoconf-archive-2022.02.11-3.fc37.noarch automake-1.16.5-9.fc37.noarch Resolves https://bugzilla.redhat.com/show_bug.cgi?id=2118243
* lvconvert: correct test support for vdo-poolZdenek Kabelac2022-08-151-0/+1
|
* WHATS_NEW: updatePeter Rajnoha2022-08-111-1/+2
|
* vdo: fix conversion of vdo_slab_size_mbZdenek Kabelac2022-06-071-0/+1
| | | | | | | | | | | | When converting VDO volume, the parameter vdo_slabSize was incorrectly copied as vdo_blockMapCacheSize, however this parameter is then no longer used for any table line creation so the wrong value was only stored in metadata. Also use just single get_kb_size_with_unit_ and remove it's duplicate functionality with get_mb_size_with_unit_. Use $VERB for vdo remove call.
* post-releaseMarian Csontos2022-05-181-0/+3
|
* pre-releasev2_03_16Marian Csontos2022-05-181-2/+8
|
* toollib: fix segfault when handling selection with historical LVsPeter Rajnoha2022-05-051-0/+1
| | | | | | | | | | | | | When processing historical LVs inside process_each_lv_in_vg for selection, we need to use dummy "_historical_lv" for select_match_lv. This is because a historical LV is not an actual LV, but only a tiny representation with subset of original properties that we recorded (name, uuid...). To use the same processing functions we use for full-fledged non-historical LVs, we need to use the prefilled "_historical_lv" structure which has all the other missing properties hard-coded.
* vdo: support --vdosettingsZdenek Kabelac2022-05-031-0/+1
| | | | | | | | Allow to use --vdosettings with lvcreate,lvconvert,lvchange. Support settings currenly only configurable via lvm.conf. With lvchange we require inactivate LV for changes to be applied. Settings block_map_era_length has supported alias block_map_period.
* thin: fix message processing on thin-pool extensionZdenek Kabelac2022-03-301-0/+1
| | | | | | When thin-pool had queued some delete message on extension operation such message has been 'lost' and thin-pool kernel metadata has been left with a thin volume that no longer existed for lvm2 metadata.
* post-releaseMarian Csontos2022-02-071-0/+3
|
* pre-releasev2_03_15Marian Csontos2022-02-071-2/+3
|
* writecache: look for settings in lvm.confDavid Teigland2022-01-311-0/+1
| | | | | | | Restore the lvm.conf cache_settings for writecache added by c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Shorter method reduces and isolates the complexity of config trees.
* Revert "writecache: handle options from lvm.conf"David Teigland2022-01-311-1/+0
| | | | | | This reverts commit c6639056e0bb2fc5f072b2c0d6bb629ad17eee6e. Next commit restores this feature.
* writecache: handle options from lvm.confZdenek Kabelac2022-01-261-0/+1
| | | | | | | | | | | | User can place default settings into lvm.conf i.e.: allocation { cache_settings { writecache { block_size = 4096 } } }
* label: cache dm device listZdenek Kabelac2021-12-201-0/+1
| | | | | | | | | | | | | | Since we check for present DM devices - cache result for futher use of checking presence of such device. lvm2 uses cache result for label scan, but also when it tries to activate or deactivate LV - however only simple target 'striped' is reasonably supported. Use disable_dm_devs to be able to control when lv_info() get cache or uncached results. TODO: support more type, however this is getting very complicated.
* devicemapper: add dm_task_get_device_listZdenek Kabelac2021-12-201-0/+1
| | | | | | | | | | | | | | | | New API extension (internal ATM) for getting a list of active DM device with extra features like i.e. uuid. To easily lookout for existing UUID in device list, there is: dm_device_list_find_by_uuid() Once the returned structure is no longer usable call: dm_device_list_destroy() Struct dm_active_device {} holds all the info, but is always allocated and destroyed within library. TODO: once it's stable, copy to libdm
* hash: raise hash table sizeZdenek Kabelac2021-12-201-0/+1
| | | | | With slightly bigger hash tables, there is considerable less hash collisions.
* post-releaseMarian Csontos2021-10-201-0/+3
|
* pre-releasev2_03_14Marian Csontos2021-10-201-2/+2
|
* WHATS_NEW: updateMarian Csontos2021-10-201-2/+2
|
* dev-cache: skip different filesystems on dir scanZdenek Kabelac2021-10-181-0/+1
| | | | | | | | When scanning configured /dev dir, avoid entring directories with different filesystem. This minimizes risk we will block on i.e. entring directory with mount point.
* archiving: refactor code to allocate less memoryZdenek Kabelac2021-10-061-0/+1
| | | | | | | | | | | | | | | | | | | | Do not store full path with each archived name reduces memory usage if the directory has thousands of entries and just add 'dir' path when needed. Also emit info print message to a user if the total size of archived files for a VG is more then 128MiB or 8192 files. TODO: Consider wheather adding a new 'lvm.conf archive{option}' to support trimming these wild archive sizes can make situation better. We already support retain_min && retain_days - but if user is generating too many and too large archives with minutes - maybe archiving should be disabled by a user - as it's not producing anything largely usable and just slows-down command ?? If we add 'retain_max & retain_max_size' the condition will go against each other and we need to chose priorities. mm
* metadata: optimize reading metadata copies in scanZdenek Kabelac2021-09-271-0/+1
| | | | | | | | | | | While being in lockless scanning phase, we can avoid reading and checking matching metadata copies if we already know them from other PV and just rely on matching metadata header information. These copies will be examined later during locked metadata read/write access. This patch may postpone discovering some read failures to locked phase.
* metadata: remember crc32 when writing vg metadataZdenek Kabelac2021-09-271-0/+1
| | | | | | | | Preserve computed crc32 check from first written PV, just like we preserve generated metadata. Also there is no need to call crc32 twice on wrapping buffer with 2 calcs, result must be always the same as with single crc32 checking.
View Lorry Controller Status