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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
init_formats() sets up the command formats, and currently sets cmd->fmt_backup
but does not set cmd->fmt to a default value. This seems incorrect so we
set it to cmd->default_settings.fmt before returning.
The call we remove here may set cmd->fmt based on a command line setting.
But it is safe to remove this, because the only caller of init_lvm() that
cares about the cmdline override is the cmdline tools (clvmd does not care),
called from lvm2_main(). After lvm2_main() calls init_lvm(), it later calls
lvm_run_command(). In lvm_run_command(), we have a call to _apply_settings(),
which has the identical assignment of cmd->fmt that this patch removes.
This is very obvious - _init_logging() makes the identical init_msg_prefix()
and init_cmd_name() calls with cmd->default_settings so these calls are
clearly redundant after calling create_toolcontext().
Very similar argument to removal of init_debug() and other calls.
create_toolcontext() calls _process_config() which sets
cmd->default_settings.activation, then calls
set_activation(cmd->default_settings.activation). Later, create_toolcontext()
sets cmd->current_settings = cmd->default_settings. So these calls
set_activation(cmd->current_settings.activation) are redundant.
Identical argument to previous patch which removed archive_enable() calls.
We add a new parameter to backup_init() which sets the enable value based
on the cmd->default_settings.backup value. This value was used to set
cmd->current_settings.backup, used in the removed backup_enable() call.
_init_backup() calls archive_init(), which originally set 'enabled' to
a hardcoded '1' value. This seems incorrect based on my read of other
areas of the code so here we add a 'enabled' paramter to archive_init().
We pass in cmd->default_settings.archive, which is obtained from the
config tree. Later in create_toolcontext, cmd->current_settings is
set to cmd->default_settings. The archive_enable() call we remove
here was using cmd->current_settings to set the 'archive' enable
value. The final value of cmd->archive_params->enabled should thus
be equivalent to the original code.
This one we actually need to move. _init_logging() is called from
create_toolcontext(), which makes this call:
/* Test mode */
cmd->default_settings.test =
find_config_tree_int(cmd, "global/test", 0);
But it does not call init_test(). So we need an init_test() somewhere.
The most logical place is to put it inside _init_logging(), since this
is where the config value is read and default_settings are set. Placing
the init_test() call here matches what is done with other variables and
seems to make sense.
This variable is set at the top of create_toolcontext() to 0.
Nothing later in create_toolcontext() changes the value.
In init_lvm(), nothing between create_toolcontext() call and this assignment
changes the value. Thus, the assignment is redundant.
The rationale for removing init_verbose() call is very similar to removing
init_debug() call. create_toolcontext() calls _init_logging() which
makes these calls:
/* Verbose level for tty output */
cmd->default_settings.verbose =
find_config_tree_int(cmd, "log/verbose", DEFAULT_VERBOSE);
init_verbose(cmd->default_settings.verbose + VERBOSE_BASE_LEVEL);
And being that create_toolcontext() copies default_settings into
current_settings at the bottom, the init_verbose() call we are removing:
init_verbose(cmd->current_settings.verbose + VERBOSE_BASE_LEVEL);
is redundant.
We can safely remove because create_toolcontext() calls _init_logging(),
which makes these calls:
/* Debug level for log file output */
cmd->default_settings.debug =
find_config_tree_int(cmd, "log/level", DEFAULT_LOGLEVEL);
init_debug(cmd->default_settings.debug);
Then at the bottom of create_toolcontext() we do this:
cmd->current_settings = cmd->default_settings;
So the call we are removing from init_lvm() functions (clvmd and lvmcmdline):
init_debug(cmd->current_settings.debug);
Just sets the value of debug based on 'cmd->current_settings.debug'.
Since cmd->current_settings is equivalent to cmd->default_settings, and
init_debug() was called with cmd->default_settings, the call we remove is
redundant.
for losetup, break out of the loop when successful setup of loop device,
and only look at 7 loop devices (default loop module setting)
for blockdev, use old option if new one is not available
with the second vgcreate overwriting the first.
Obtain lock before calling vg_create(), which checks for existence of vgname
and fails if it already exists.
Prior to this patch, "lvremove -f vgname" would fail if vgname contained
one or more snapshot LVs. Now this passes, but has a side-effect.
If you issue "lvremove vgname" where vgname contains one or more snaps,
you will get an extra "y/n" prompt to remove the same snapshot.
Example:
$ lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lvsnap vgtest swi-a- 16.00M lvtest 0.05
lvtest vgtest owi-a- 64.00M
$ lvremove vgtest
Do you really want to remove active logical volume "lvsnap"? [y/n]: n
Logical volume "lvsnap" not removed
Do you really want to remove active logical volume "lvsnap"? [y/n]: n
Logical volume "lvsnap" not removed
Command failed with status code 5.
Fixing this will most likely require modification of the iterator
function, process_each_lvs_in_vg() to iterate over snaps in some
cases (e.g. lvs, vgdisplay -v) but not in others (lvremove).
