IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In libdm, we only ever use 'fields', while the tools use 'options' and
'fields' interchangeably.
Ideally it would be good to use 'fields' consistently everywhere.
However, 'options' most likely comes from the tool commandline '-o' and
'--options' which cannot be changed.
We display '0' for these fields now in this case. Ideally these values are
undefined for an orphan PV but today there is no way to specify undefined
with display functions such as _size64_disp().
"test" never prints anything. Therefore, "return $(test ...)" is equivalent to
just "return;" which means success in sh (same as return 0). We can however,
thanks to set -e, use "test foo = bar" as an assertion.
PS: test a == b is invalid syntax. It is either = or -eq: = is textual and -eq
is numeric comparison.
For example in LVM2, "pv_all" gives all PV fields.
"seg_all" gives all LV segment fields.
"all" gives all fields of the final report type. I think this is more
useful than just adding the current prefix.
So "lvs -o seg_all" gives all the LV segment fields, whilst
"lvs --segments -o all" adds in LV and VG fields too.
"lvs -o all -O vg_name" has report type LVS+VGS so includes all LV and all
VG fields.
Reports the size of the smallest metadata area in a PV or a VG.
Useful to confirm pvcreate --metadatasize or pvmetadatasize setting in
/etc/lvm/lvm.conf file.
NOTE: Actual value in these fields will most always differ from that
given in pvcreate options due to rounding and alignment effects.
There is a rudimentary make file in place so people can build by hand
from 'LVM2/daemons/clogd'. It is not hooked into the main build system
yet. I am checking this in to provide people better access to the
source code.
There is still work to be done to make better use of existing code in
the LVM repository. (list.h could be removed in favor of existing list
implementations, for example. Logging might also be removed in favor
of what is already in the tree.)
I will probably defer updating WHATS_NEW_DM until this code is linked
into the main build system (unless otherwise instructed).
Checks added for DM device names to allow only names < DM_NAME_LEN,
otherwise a part of lengthy name would be silently ignored and could
cause confusion while using dmsetup. Also, the name should not contain
'/' character, if it is used in context of creating a new device
or renaming the existing one (because we do not consider full path
to devices, they do not exist in filesystem yet) and appropriate error
messages are shown.
pvcreate $DEV
vgcreate -s 1k vg_test $DEV
lvcreate -l 1 -n lv1 vg_test
..
/dev/vg_test/lv1: write failed after 1024 of 4096 at 0: No space left on device
Just check for maximum write size in set_lv.
It fails for 1k PE now.
Patch adds log_region_size into allocation habdle struct
and use it in _alloc_parallel_area() for proper log size calculation
instead of hardcoded 1 extent - which can fail.
Reproducer for incorrect log size calculation:
DEV=/dev/sd[bcd]
pvcreate $DEV
vgcreate -s 1k vg_test $DEV
lvcreate -m1 -L 12M -n mirr vg_test
https://bugzilla.redhat.com/show_bug.cgi?id=477040
The log size calculation is mostly copied from kernel code.
Check for major/minor collision is added in _add_dev_to_dtree()
where we already read info by uuid,
so in the case of requesting major/minor it queries device-mapper
by major/minor for device availability.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=204992
Very simple / crude method of removing 'is_static' from initialization.
Why should we require an application tell us whether it is linked
statically or dynamically to libLVM? If the application is linked
statically, but libraries exist and dlopen() calls succeed, why
do we care if it's statically linked?
This allows us to remove one argument from create_toolcontext() and
moves it closer to a generic library init function.
In the arg_*() functions, we just use _the_args() directly.
For now we leave the first parameter to these
arg_*() functions (struct cmd_context *) because
of the number of files involved in removing the
parameter.
In preparation for removing cmd->args.
IMO, it makes more sense to put these accessor functions
in the same location as the static array _the_args.
Next patch will update arg_* functions to use _the_args[]
directly and remove cmd->args.
Problem is dm_report_init() may return NULL and subsequent call to
dm_report_set_output_field_name_prefix() doesn't handle NULL value.
Example:
pvs --nameprefixes --rows --unquoted --noheadings -opv_name,fred
Logical Volume Fields
---------------------
lv_uuid - Unique identifier
lv_name - Name. LVs created for internal use are enclosed in brackets.
...
Physical Volume Segment Fields
------------------------------
pvseg_start - Physical Extent number of start of segment.
pvseg_size - Number of extents in segment.
Unrecognised field: fred
Segmentation fault
Move init_full_scan_done(0) and init_mirror_in_sync(0) from init_lvm()
after call to create_toolcontext() to _init_globals(), called from bottom
of create_toolcontext(). No functional change.
Author: Dave Wysochanski <dwysocha@redhat.com>
Acked-by: James Cameron <james.cameron@hp.com>
Acked-by: Alasdair G Kergon <agk@redhat.com>
