2001-10-02 21:09:05 +04:00
/*
2004-03-30 23:35:44 +04:00
* Copyright ( C ) 2001 - 2004 Sistina Software , Inc . All rights reserved .
2012-03-03 22:32:53 +04:00
* Copyright ( C ) 2004 - 2012 Red Hat , Inc . All rights reserved .
2001-10-02 21:09:05 +04:00
*
2004-03-30 23:35:44 +04:00
* This file is part of LVM2 .
2001-10-02 21:09:05 +04:00
*
2004-03-30 23:35:44 +04:00
* This copyrighted material is made available to anyone wishing to use ,
* modify , copy , or redistribute it subject to the terms and conditions
2007-08-21 00:55:30 +04:00
* of the GNU Lesser General Public License v .2 .1 .
2001-10-02 21:09:05 +04:00
*
2007-08-21 00:55:30 +04:00
* You should have received a copy of the GNU Lesser General Public License
2004-03-30 23:35:44 +04:00
* along with this program ; if not , write to the Free Software Foundation ,
2016-01-21 13:49:46 +03:00
* Inc . , 51 Franklin Street , Fifth Floor , Boston , MA 02110 - 1301 USA
2001-10-02 21:09:05 +04:00
*/
# include "tools.h"
2012-02-23 17:11:07 +04:00
# include "lvmetad.h"
# include "lvmcache.h"
2015-10-19 21:58:43 +03:00
struct pvscan_params {
int new_pvs_found ;
int pvs_found ;
uint64_t size_total ;
uint64_t size_new ;
unsigned pv_max_name_len ;
unsigned vg_max_name_len ;
unsigned pv_tmp_namelen ;
char * pv_tmp_name ;
} ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
struct pvscan_aa_params {
int refresh_all ;
unsigned int activate_errors ;
struct dm_list changed_vgnames ;
} ;
2015-10-19 21:58:43 +03:00
static int _pvscan_display_single ( struct cmd_context * cmd ,
struct physical_volume * pv ,
struct pvscan_params * params )
2002-11-18 17:04:08 +03:00
{
2014-03-19 03:17:36 +04:00
/* XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX */
char uuid [ 40 ] __attribute__ ( ( aligned ( 8 ) ) ) ;
2015-10-19 21:58:43 +03:00
const unsigned suffix_len = sizeof ( uuid ) + 10 ;
unsigned pv_len ;
2014-03-19 03:17:36 +04:00
const char * pvdevname = pv_dev_name ( pv ) ;
2002-11-18 17:04:08 +03:00
/* short listing? */
2016-06-22 00:24:52 +03:00
if ( arg_is_set ( cmd , short_ARG ) ) {
2014-03-19 03:19:01 +04:00
log_print_unless_silent ( " %s " , pvdevname ) ;
2015-10-19 21:58:43 +03:00
return ECMD_PROCESSED ;
2002-11-18 17:04:08 +03:00
}
2015-10-19 21:58:43 +03:00
if ( ! params - > pv_max_name_len ) {
lvmcache_get_max_name_lengths ( cmd , & params - > pv_max_name_len , & params - > vg_max_name_len ) ;
2002-11-18 17:04:08 +03:00
2015-10-19 21:58:43 +03:00
params - > pv_max_name_len + = 2 ;
params - > vg_max_name_len + = 2 ;
params - > pv_tmp_namelen = params - > pv_max_name_len + suffix_len ;
2002-11-18 17:04:08 +03:00
2015-10-19 21:58:43 +03:00
if ( ! ( params - > pv_tmp_name = dm_pool_alloc ( cmd - > mem , params - > pv_tmp_namelen ) ) )
return ECMD_FAILED ;
2002-11-18 17:04:08 +03:00
}
2015-10-19 21:58:43 +03:00
pv_len = params - > pv_max_name_len ;
memset ( params - > pv_tmp_name , 0 , params - > pv_tmp_namelen ) ;
2016-06-22 00:24:52 +03:00
if ( arg_is_set ( cmd , uuid_ARG ) ) {
2002-11-18 17:04:08 +03:00
if ( ! id_write_format ( & pv - > id , uuid , sizeof ( uuid ) ) ) {
stack ;
2015-10-19 21:58:43 +03:00
return ECMD_FAILED ;
2002-11-18 17:04:08 +03:00
}
2015-10-19 21:58:43 +03:00
if ( dm_snprintf ( params - > pv_tmp_name , params - > pv_tmp_namelen , " %-*s with UUID %s " ,
params - > pv_max_name_len - 2 , pvdevname , uuid ) < 0 ) {
2014-03-19 03:17:36 +04:00
log_error ( " Invalid PV name with uuid. " ) ;
2015-10-19 21:58:43 +03:00
return ECMD_FAILED ;
2014-03-19 03:17:36 +04:00
}
2015-10-19 21:58:43 +03:00
pvdevname = params - > pv_tmp_name ;
pv_len + = suffix_len ;
2002-11-18 17:04:08 +03:00
}
2014-03-19 03:17:36 +04:00
if ( is_orphan ( pv ) )
config: add silent mode
Accept -q as the short form of --quiet.
Suppress non-essential standard output if -q is given twice.
Treat log/silent in lvm.conf as equivalent to -qq.
Review all log_print messages and change some to
log_print_unless_silent.
When silent, the following commands still produce output:
dumpconfig, lvdisplay, lvmdiskscan, lvs, pvck, pvdisplay,
pvs, version, vgcfgrestore -l, vgdisplay, vgs.
[Needs checking.]
Non-essential messages are shifted from log level 4 to log level 5
for syslog and lvm2_log_fn purposes.
2012-08-25 23:35:48 +04:00
log_print_unless_silent ( " PV %-*s %-*s %s [%s] " ,
2014-03-19 03:17:36 +04:00
pv_len , pvdevname ,
2015-10-19 21:58:43 +03:00
params - > vg_max_name_len , " " ,
config: add silent mode
Accept -q as the short form of --quiet.
Suppress non-essential standard output if -q is given twice.
Treat log/silent in lvm.conf as equivalent to -qq.
Review all log_print messages and change some to
log_print_unless_silent.
When silent, the following commands still produce output:
dumpconfig, lvdisplay, lvmdiskscan, lvs, pvck, pvdisplay,
pvs, version, vgcfgrestore -l, vgdisplay, vgs.
[Needs checking.]
Non-essential messages are shifted from log level 4 to log level 5
for syslog and lvm2_log_fn purposes.
2012-08-25 23:35:48 +04:00
pv - > fmt ? pv - > fmt - > name : " " ,
display_size ( cmd , pv_size ( pv ) ) ) ;
2014-03-19 03:17:36 +04:00
else if ( pv_status ( pv ) & EXPORTED_VG )
log_print_unless_silent ( " PV %-*s is in exported VG %s [%s / %s free] " ,
pv_len , pvdevname , pv_vg_name ( pv ) ,
display_size ( cmd , ( uint64_t ) pv_pe_count ( pv ) * pv_pe_size ( pv ) ) ,
display_size ( cmd , ( uint64_t ) ( pv_pe_count ( pv ) - pv_pe_alloc_count ( pv ) ) * pv_pe_size ( pv ) ) ) ;
else
log_print_unless_silent ( " PV %-*s VG %-*s %s [%s / %s free] " ,
pv_len , pvdevname ,
2015-10-19 21:58:43 +03:00
params - > vg_max_name_len , pv_vg_name ( pv ) ,
2014-03-19 03:17:36 +04:00
pv - > fmt ? pv - > fmt - > name : " " ,
config: add silent mode
Accept -q as the short form of --quiet.
Suppress non-essential standard output if -q is given twice.
Treat log/silent in lvm.conf as equivalent to -qq.
Review all log_print messages and change some to
log_print_unless_silent.
When silent, the following commands still produce output:
dumpconfig, lvdisplay, lvmdiskscan, lvs, pvck, pvdisplay,
pvs, version, vgcfgrestore -l, vgdisplay, vgs.
[Needs checking.]
Non-essential messages are shifted from log level 4 to log level 5
for syslog and lvm2_log_fn purposes.
2012-08-25 23:35:48 +04:00
display_size ( cmd , ( uint64_t ) pv_pe_count ( pv ) * pv_pe_size ( pv ) ) ,
display_size ( cmd , ( uint64_t ) ( pv_pe_count ( pv ) - pv_pe_alloc_count ( pv ) ) * pv_pe_size ( pv ) ) ) ;
2015-10-19 21:58:43 +03:00
return ECMD_PROCESSED ;
}
static int _pvscan_single ( struct cmd_context * cmd , struct volume_group * vg ,
struct physical_volume * pv , struct processing_handle * handle )
{
struct pvscan_params * params = ( struct pvscan_params * ) handle - > custom_handle ;
2016-06-22 00:24:52 +03:00
if ( ( arg_is_set ( cmd , exported_ARG ) & & ! ( pv_status ( pv ) & EXPORTED_VG ) ) | |
( arg_is_set ( cmd , novolumegroup_ARG ) & & ( ! is_orphan ( pv ) ) ) ) {
2015-10-19 21:58:43 +03:00
return ECMD_PROCESSED ;
}
params - > pvs_found + + ;
if ( is_orphan ( pv ) ) {
params - > new_pvs_found + + ;
params - > size_new + = pv_size ( pv ) ;
params - > size_total + = pv_size ( pv ) ;
} else {
params - > size_total + = ( uint64_t ) pv_pe_count ( pv ) * pv_pe_size ( pv ) ;
}
_pvscan_display_single ( cmd , pv , params ) ;
return ECMD_PROCESSED ;
2002-11-18 17:04:08 +03:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
static int _lvmetad_clear_dev ( dev_t devno , int32_t major , int32_t minor )
2012-06-27 17:35:11 +04:00
{
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
char buf [ 24 ] ;
2012-12-12 15:51:28 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
( void ) dm_snprintf ( buf , sizeof ( buf ) , FMTi32 " : " FMTi32 , major , minor ) ;
2012-06-27 17:35:11 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( ! lvmetad_pv_gone ( devno , buf ) )
2013-04-29 14:34:50 +04:00
return_0 ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
log_print_unless_silent ( " Device %s not found. Cleared from lvmetad cache. " , buf ) ;
2016-04-27 23:33:23 +03:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
return 1 ;
}
2016-04-27 23:33:23 +03:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
/*
* pvscan - - cache does not perform any lvmlockd locking , and
* pvscan - - cache - aay skips autoactivation in lockd VGs .
*
* pvscan - - cache populates lvmetad with VG metadata from disk .
* No lvmlockd locking is needed . It is expected that lockd VG
* metadata that is read by pvscan and populated in lvmetad may
* be immediately stale due to changes to the VG from other hosts
* during or after this pvscan . This is normal and not a problem .
* When a subsequent lvm command uses the VG , it will lock the VG
* with lvmlockd , read the VG from lvmetad , and update the cached
* copy from disk if necessary .
*
* pvscan - - cache - aay does not activate LVs in lockd VGs because
* activation requires locking , and a lock - start operation is needed
* on a lockd VG before any locking can be performed in it .
*
* An equivalent of pvscan - - cache - aay for lockd VGs is :
* 1. pvscan - - cache
* 2. vgchange - - lock - start
* 3. vgchange - aay - S ' locktype = sanlock | | locktype = dlm '
*
* [ We could eventually add support for autoactivating lockd VGs
* using pvscan by incorporating the lock start step ( which can
* take a long time ) , but there may be a better option than
* continuing to overload pvscan . ]
*
* Stages of starting a lockd VG :
*
* . pvscan - - cache populates lockd VGs in lvmetad without locks ,
* and this initial cached copy may quickly become stale .
*
* . vgchange - - lock - start VG reads the VG without the VG lock
* because no locks are available until the locking is started .
* It only uses the VG name and lock_type from the VG metadata ,
* and then only uses it to start the VG lockspace in lvmlockd .
*
* . Further lvm commands , e . g . activation , can then lock the VG
* with lvmlockd and use current VG metdata .
*/
2012-12-12 15:51:28 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
# define REFRESH_BEFORE_AUTOACTIVATION_RETRIES 5
# define REFRESH_BEFORE_AUTOACTIVATION_RETRY_USLEEP_DELAY 100000
2016-04-27 23:33:23 +03:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
static int _pvscan_autoactivate_single ( struct cmd_context * cmd , const char * vg_name ,
struct volume_group * vg , struct processing_handle * handle )
{
struct pvscan_aa_params * pp = ( struct pvscan_aa_params * ) handle - > custom_handle ;
unsigned int refresh_retries = REFRESH_BEFORE_AUTOACTIVATION_RETRIES ;
int refresh_done = 0 ;
2013-09-03 18:45:18 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( vg_is_clustered ( vg ) )
return ECMD_PROCESSED ;
2016-11-03 00:29:52 +03:00
if ( vg_is_exported ( vg ) )
return ECMD_PROCESSED ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( is_lockd_type ( vg - > lock_type ) )
return ECMD_PROCESSED ;
log_debug ( " pvscan autoactivating VG %s. " , vg_name ) ;
/*
* Refresh LVs in a VG that has " changed " from finding a PV .
* The meaning of " changed " is determined in lvmetad , and is
* returned to the command as a flag .
*
* FIXME : There ' s a tiny race when suspending the device which is part
2013-11-12 13:55:34 +04:00
* of the refresh because when suspend ioctl is performed , the dm
* kernel driver executes ( do_suspend and dm_suspend kernel fn ) :
*
* step 1 : a check whether the dev is already suspended and
* if yes it returns success immediately as there ' s
* nothing to do
* step 2 : it grabs the suspend lock
* step 3 : another check whether the dev is already suspended
* and if found suspended , it exits with - EINVAL now
*
* The race can occur in between step 1 and step 2. To prevent premature
* autoactivation failure , we ' re using a simple retry logic here before
* we fail completely . For a complete solution , we need to fix the
* locking so there ' s no possibility for suspend calls to interleave
* each other to cause this kind of race .
*
* Remove this workaround with " refresh_retries " once we have proper locking in !
*/
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( pp - > refresh_all | | str_list_match_item ( & pp - > changed_vgnames , vg_name ) ) {
2014-03-14 13:44:14 +04:00
while ( refresh_retries - - ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
log_debug_activation ( " Refreshing VG %s before autoactivation. " , vg_name ) ;
if ( vg_refresh_visible ( cmd , vg ) ) {
2014-03-14 13:44:14 +04:00
refresh_done = 1 ;
break ;
}
usleep ( REFRESH_BEFORE_AUTOACTIVATION_RETRY_USLEEP_DELAY ) ;
2013-11-12 13:55:34 +04:00
}
2014-03-14 13:44:14 +04:00
if ( ! refresh_done )
log_warn ( " %s: refresh before autoactivation failed. " , vg - > name ) ;
}
2012-12-12 15:51:28 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
log_debug_activation ( " Autoactivating VG %s. " , vg_name ) ;
if ( ! vgchange_activate ( cmd , vg , CHANGE_AAY ) ) {
2012-06-27 17:35:11 +04:00
log_error ( " %s: autoactivation failed. " , vg - > name ) ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
pp - > activate_errors + + ;
2013-09-03 18:45:18 +04:00
goto out ;
2012-06-27 17:35:11 +04:00
}
2016-01-07 17:17:08 +03:00
/*
* After sucessfull activation we need to initialise polling
* for all activated LVs in a VG . Possible enhancement would
* be adding - - poll y | n cmdline option for pvscan and call
* init_background_polling routine in autoactivation handler .
*/
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
log_debug_activation ( " Starting background polling for VG %s. " , vg_name ) ;
2013-09-03 18:45:18 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( ! ( vgchange_background_polling ( cmd , vg ) ) )
goto_out ;
2013-09-03 18:45:18 +04:00
out :
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
return ECMD_PROCESSED ;
2012-06-27 17:35:11 +04:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
static int _pvscan_autoactivate ( struct cmd_context * cmd , struct pvscan_aa_params * pp ,
int all_vgs , struct dm_list * vgnames )
2013-10-22 15:52:18 +04:00
{
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
struct processing_handle * handle = NULL ;
int ret ;
2013-10-22 15:52:18 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( ! all_vgs & & dm_list_empty ( vgnames ) ) {
log_debug ( " No VGs to autoactivate. " ) ;
return ECMD_PROCESSED ;
}
2014-06-16 14:38:14 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( ! lvmetad_used ( ) )
log_warn ( " WARNING: Autoactivation reading from disk instead of lvmetad. " ) ;
2016-05-31 13:24:05 +03:00
if ( ! ( handle = init_processing_handle ( cmd , NULL ) ) ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
log_error ( " Failed to initialize processing handle. " ) ;
return ECMD_FAILED ;
}
2013-10-22 15:52:18 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
handle - > custom_handle = pp ;
2013-10-22 15:52:18 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( all_vgs ) {
cmd - > command - > flags | = ALL_VGS_IS_DEFAULT ;
pp - > refresh_all = 1 ;
}
dev_cache_full_scan ( cmd - > full_filter ) ;
2016-05-03 12:46:28 +03:00
ret = process_each_vg ( cmd , 0 , NULL , NULL , vgnames , 0 , 0 , handle , _pvscan_autoactivate_single ) ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
destroy_processing_handle ( cmd , handle ) ;
return ret ;
2013-10-22 15:52:18 +04:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
static int _pvscan_cache ( struct cmd_context * cmd , int argc , char * * argv )
2012-03-03 22:32:53 +04:00
{
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
struct pvscan_aa_params pp = { 0 } ;
struct dm_list found_vgnames ;
2012-03-03 22:32:53 +04:00
struct device * dev ;
const char * pv_name ;
2016-04-27 23:06:43 +03:00
const char * reason = NULL ;
2012-03-06 06:30:49 +04:00
int32_t major = - 1 ;
int32_t minor = - 1 ;
int devno_args = 0 ;
struct arg_value_group_list * current_group ;
2012-03-03 22:32:53 +04:00
dev_t devno ;
2016-06-16 20:04:05 +03:00
int do_activate ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
int all_vgs = 0 ;
int remove_errors = 0 ;
int add_errors = 0 ;
int ret = ECMD_PROCESSED ;
dm_list_init ( & found_vgnames ) ;
dm_list_init ( & pp . changed_vgnames ) ;
2012-03-06 06:30:49 +04:00
2016-06-16 20:04:05 +03:00
do_activate = arg_is_set ( cmd , activate_ARG ) ;
if ( ! lvmetad_used ( ) & & ! do_activate ) {
log_verbose ( " Ignoring pvscan --cache because lvmetad is not in use. " ) ;
2012-11-09 18:56:57 +04:00
return ret ;
}
2016-06-16 20:04:05 +03:00
if ( do_activate & & ( arg_uint_value ( cmd , activate_ARG , CHANGE_AAY ) ! = CHANGE_AAY ) ) {
log_error ( " Only --activate ay allowed with pvscan. " ) ;
return 0 ;
}
if ( ! lvmetad_used ( ) & & do_activate & & ! find_config_tree_bool ( cmd , global_use_lvmetad_CFG , NULL ) ) {
log_verbose ( " Ignoring pvscan --cache -aay because lvmetad is not in use. " ) ;
return ret ;
2012-06-27 17:35:11 +04:00
}
2016-06-22 00:24:52 +03:00
if ( arg_is_set ( cmd , major_ARG ) + arg_is_set ( cmd , minor_ARG ) )
2012-03-06 06:30:49 +04:00
devno_args = 1 ;
2012-03-03 22:32:53 +04:00
2016-06-22 00:24:52 +03:00
if ( devno_args & & ( ! arg_is_set ( cmd , major_ARG ) | | ! arg_is_set ( cmd , minor_ARG ) ) ) {
2012-03-06 06:30:49 +04:00
log_error ( " Both --major and --minor required to identify devices. " ) ;
return EINVALID_CMD_LINE ;
}
2013-03-18 00:29:58 +04:00
if ( ! lock_vol ( cmd , VG_GLOBAL , LCK_VG_READ , NULL ) ) {
2012-03-02 20:58:41 +04:00
log_error ( " Unable to obtain global lock. " ) ;
return ECMD_FAILED ;
}
2016-06-16 20:04:05 +03:00
/*
* This a special case where use_lvmetad = 1 in lvm . conf but pvscan
* cannot use lvmetad for some reason . In this case pvscan should
* still activate LVs even though it ' s not updating the cache .
*/
if ( do_activate & & ! lvmetad_used ( ) ) {
log_verbose ( " Activating all VGs without lvmetad. " ) ;
2016-06-15 22:19:18 +03:00
all_vgs = 1 ;
devno_args = 0 ;
goto activate ;
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
/*
* Scan all devices when no args are given .
*/
2012-03-06 06:30:49 +04:00
if ( ! argc & & ! devno_args ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
log_verbose ( " Scanning all devices. " ) ;
if ( ! lvmetad_pvscan_all_devs ( cmd , 1 ) ) {
log_warn ( " WARNING: Not using lvmetad because cache update failed. " ) ;
lvmetad_make_unused ( cmd ) ;
2016-01-29 01:40:26 +03:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( lvmetad_used ( ) & & lvmetad_is_disabled ( cmd , & reason ) ) {
log_warn ( " WARNING: Not using lvmetad because %s. " , reason ) ;
lvmetad_make_unused ( cmd ) ;
}
all_vgs = 1 ;
goto activate ;
}
/*
* FIXME : when specific devs are named , we generally don ' t want to scan
* any other devs , but if lvmetad is not yet populated , the first
* ' pvscan - - cache dev ' does need to do a full scan . We want to remove
* the need for this case so that ' pvscan - - cache dev ' is guaranteed to
* never scan any devices other than those specified .
*/
if ( ! lvmetad_token_matches ( cmd ) ) {
log_verbose ( " Scanning all devices to initialize lvmetad. " ) ;
if ( lvmetad_used ( ) & & ! lvmetad_pvscan_all_devs ( cmd , 0 ) ) {
log_warn ( " WARNING: Not using lvmetad because cache update failed. " ) ;
lvmetad_make_unused ( cmd ) ;
}
if ( lvmetad_used ( ) & & lvmetad_is_disabled ( cmd , & reason ) ) {
log_warn ( " WARNING: Not using lvmetad because %s. " , reason ) ;
lvmetad_make_unused ( cmd ) ;
}
all_vgs = 1 ;
goto activate ;
2012-03-03 22:32:53 +04:00
}
2016-04-27 23:06:43 +03:00
/*
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
* When args are given , scan only those devices . If lvmetad is already
* disabled , a full scan is required to reenable it , so there ' s no
* point in doing individual device scans , so go directly to
* autoactivation . ( FIXME : Should we also skip autoactivation in this
* case since that will read disks with lvmetad disabled ?
* i . e . avoid disk access and not activate LVs , or or read from disk
* and activate LVs ? )
2016-04-27 23:06:43 +03:00
*/
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( lvmetad_is_disabled ( cmd , & reason ) ) {
2016-04-27 23:06:43 +03:00
log_warn ( " WARNING: Not using lvmetad because %s. " , reason ) ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
lvmetad_make_unused ( cmd ) ;
all_vgs = 1 ;
goto activate ;
2016-04-27 23:06:43 +03:00
}
2016-01-29 01:40:26 +03:00
/*
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
* Step 1 : for each device , if it ' s no longer found , then tell lvmetad
* to drop it . If the device exists , read metadata from it and send
* that to lvmetad .
*
* When given a device name , check if the device is not visible to
* lvmetad , but still visible to the system , and if so , tell lvmetad to
* drop it ( using the major : minor from the system ) .
*
* When given a major : minor which is not visible to the system , just
* tell lvmetad to drop it directly using that major : minor .
*
* When a device has left the system , it must be dropped using
* - - major / - - minor because we cannot map the device name to major : minor
* after the device has left . ( A full rescan could of course be used
* to drop any devices that have left . )
2016-01-29 01:40:26 +03:00
*/
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( argc | | devno_args )
log_verbose ( " Scanning devices on command line. " ) ;
2012-03-03 22:32:53 +04:00
2012-03-02 20:58:41 +04:00
while ( argc - - ) {
2012-03-03 22:32:53 +04:00
pv_name = * argv + + ;
2013-10-22 15:52:18 +04:00
if ( pv_name [ 0 ] = = ' / ' ) {
if ( ! ( dev = dev_cache_get ( pv_name , cmd - > lvmetad_filter ) ) ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
/* Remove device path from lvmetad. */
log_debug ( " Removing dev %s from lvmetad cache. " , pv_name ) ;
2015-01-12 15:50:11 +03:00
if ( ( dev = dev_cache_get ( pv_name , NULL ) ) ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( ! _lvmetad_clear_dev ( dev - > dev , MAJOR ( dev - > dev ) , MINOR ( dev - > dev ) ) )
remove_errors + + ;
2015-01-12 15:50:11 +03:00
} else {
log_error ( " Physical Volume %s not found. " , pv_name ) ;
ret = ECMD_FAILED ;
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
} else {
/* Add device path to lvmetad. */
log_debug ( " Scanning dev %s for lvmetad cache. " , pv_name ) ;
if ( ! lvmetad_pvscan_single ( cmd , dev , & found_vgnames , & pp . changed_vgnames ) )
add_errors + + ;
2013-10-22 15:52:18 +04:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
} else {
2013-10-22 15:52:18 +04:00
if ( sscanf ( pv_name , " %d:%d " , & major , & minor ) ! = 2 ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
log_warn ( " WARNING: Failed to parse major:minor from %s, skipping. " , pv_name ) ;
2013-10-22 15:52:18 +04:00
continue ;
}
2015-05-07 12:03:48 +03:00
devno = MKDEV ( ( dev_t ) major , ( dev_t ) minor ) ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
2013-10-22 15:52:18 +04:00
if ( ! ( dev = dev_cache_get_by_devt ( devno , cmd - > lvmetad_filter ) ) ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
/* Remove major:minor from lvmetad. */
log_debug ( " Removing dev %d:%d from lvmetad cache. " , major , minor ) ;
if ( ! _lvmetad_clear_dev ( devno , major , minor ) )
remove_errors + + ;
} else {
/* Add major:minor to lvmetad. */
log_debug ( " Scanning dev %d:%d for lvmetad cache. " , major , minor ) ;
if ( ! lvmetad_pvscan_single ( cmd , dev , & found_vgnames , & pp . changed_vgnames ) )
add_errors + + ;
2013-10-22 15:52:18 +04:00
}
2012-03-06 06:30:49 +04:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
2013-07-01 18:30:12 +04:00
if ( sigint_caught ( ) ) {
2012-03-06 06:30:49 +04:00
ret = ECMD_FAILED ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
goto_out ;
2013-07-01 18:30:12 +04:00
}
2012-03-06 06:30:49 +04:00
}
if ( ! devno_args )
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
goto activate ;
2012-03-06 06:30:49 +04:00
/* Process any grouped --major --minor args */
dm_list_iterate_items ( current_group , & cmd - > arg_value_groups ) {
major = grouped_arg_int_value ( current_group - > arg_values , major_ARG , major ) ;
minor = grouped_arg_int_value ( current_group - > arg_values , minor_ARG , minor ) ;
if ( major < 0 | | minor < 0 )
continue ;
2015-05-07 12:03:48 +03:00
devno = MKDEV ( ( dev_t ) major , ( dev_t ) minor ) ;
2012-03-06 06:30:49 +04:00
2013-07-22 17:03:56 +04:00
if ( ! ( dev = dev_cache_get_by_devt ( devno , cmd - > lvmetad_filter ) ) ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
/* Remove major:minor from lvmetad. */
log_debug ( " Removing dev %d:%d from lvmetad cache. " , major , minor ) ;
if ( ! _lvmetad_clear_dev ( devno , major , minor ) )
remove_errors + + ;
} else {
/* Add major:minor to lvmetad. */
log_debug ( " Scanning dev %d:%d for lvmetad cache. " , major , minor ) ;
if ( ! lvmetad_pvscan_single ( cmd , dev , & found_vgnames , & pp . changed_vgnames ) )
add_errors + + ;
2012-03-03 22:32:53 +04:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
2013-07-01 18:30:12 +04:00
if ( sigint_caught ( ) ) {
ret = ECMD_FAILED ;
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
goto_out ;
2012-03-02 20:58:41 +04:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
}
2012-03-03 22:32:53 +04:00
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
/*
* In the process of scanning devices , lvmetad may have become
* disabled . If so , revert to scanning for the autoactivation step .
* Only autoactivate the VGs that were found during the dev scans .
*/
if ( lvmetad_used ( ) & & lvmetad_is_disabled ( cmd , & reason ) ) {
log_warn ( " WARNING: Not using lvmetad because %s. " , reason ) ;
lvmetad_make_unused ( cmd ) ;
2012-03-02 20:58:41 +04:00
}
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
activate :
/*
* Step 2 : when the PV was sent to lvmetad , the lvmetad reply
* indicated if all the PVs for the VG are now found . If so ,
* the vgname was added to the list , and we can attempt to
* autoactivate LVs in the VG .
*/
if ( do_activate )
ret = _pvscan_autoactivate ( cmd , & pp , all_vgs , & found_vgnames ) ;
2012-03-03 22:32:53 +04:00
out :
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( remove_errors | | add_errors | | pp . activate_errors )
ret = ECMD_FAILED ;
2015-06-30 20:54:38 +03:00
if ( ! sync_local_dev_names ( cmd ) )
stack ;
lvmetad: two phase vg_update
Previously, a command sent lvmetad new VG metadata in vg_commit().
In vg_commit(), devices are suspended, so any memory allocation
done by the command while sending to lvmetad, or by lvmetad while
updating its cache could deadlock if memory reclaim was triggered.
Now lvmetad is updated in unlock_vg(), after devices are resumed.
The new method for updating VG metadata in lvmetad is in two phases:
1. In vg_write(), before devices are suspended, the command sends
lvmetad a short message ("set_vg_info") telling it what the new
VG seqno will be. lvmetad sees that the seqno is newer than
the seqno of its cached VG, so it sets the INVALID flag for the
cached VG. If sending the message to lvmetad fails, the command
fails before the metadata is committed and the change is not made.
If sending the message succeeds, vg_commit() is called.
2. In unlock_vg(), after devices are resumed, the command sends
lvmetad the standard vg_update message with the new metadata.
lvmetad sees that the seqno in the new metadata matches the
seqno it saved from set_vg_info, and knows it has the latest
copy, so it clears the INVALID flag for the cached VG.
If a command fails between 1 and 2 (after committing the VG on disk,
but before sending lvmetad the new metadata), the cached VG retains
the INVALID flag in lvmetad. A subsequent command will read the
cached VG from lvmetad, see the INVALID flag, ignore the cached
copy, read the VG from disk instead, update the lvmetad copy
with the latest copy from disk, (this clears the INVALID flag
in lvmetad), and use the correct VG metadata for the command.
(This INVALID mechanism already existed for use by lvmlockd.)
2016-06-08 22:42:03 +03:00
unlock_vg ( cmd , NULL , VG_GLOBAL ) ;
2012-03-02 20:58:41 +04:00
return ret ;
}
2016-04-06 23:31:15 +03:00
/*
* Three main pvscan cases related to lvmetad usage :
* 1. pvscan
* 2. pvscan - - cache
* 3. pvscan - - cache < dev >
*
* 1. The ' pvscan ' command ( without - - cache ) may or may not attempt to
* repopulate the lvmetad cache , and may or may not use the lvmetad
* cache to display PV info :
*
* i . If lvmetad is being used and is in a normal state , then ' pvscan '
* will simply read and display PV info from the lvmetad cache .
*
* ii . If lvmetad is not being used , ' pvscan ' will read all devices to
* display the PV info .
*
* iii . If lvmetad is being used , but has been disabled ( because of
* duplicate devs or lvm1 metadata ) , or has a non - matching token
* ( because the device filter is different from the device filter last
* used to populate lvmetad ) , then ' pvscan ' will begin by rescanning
* devices to repopulate lvmetad . If lvmetad is enabled after the
* rescan , then ' pvscan ' will simply read and display PV info from the
* lvmetad cache ( like case i ) . If lvmetad is disabled after the
* rescan , then ' pvscan ' will read all devices to display PV info
* ( like case ii ) .
*
* 2. The ' pvscan - - cache ' command ( without named devs ) will always
* attempt to repopulate the lvmetad cache by rescanning all devs
* ( regardless of whether lvmetad was previously disabled or had an
* unmatching token . ) lvmetad may be enabled or disabled after the
* rescan ( depending on whether duplicate devs or lvm1 metadata was
* found ) .
*
* 3. The ' pvscan - - cache < dev > ' command will attempt to repopulate the
* lvmetad cache by rescanning all devs if lvmetad has a non - matching
* token ( e . g . because it has not yet been populated , see FIXME above ) .
* Otherwise , the command will only rescan the named < dev > and send
* their metadata to lvmetad .
*/
2012-02-23 17:11:07 +04:00
int pvscan ( struct cmd_context * cmd , int argc , char * * argv )
2001-10-02 21:09:05 +04:00
{
2015-10-19 21:58:43 +03:00
struct pvscan_params params = { 0 } ;
struct processing_handle * handle = NULL ;
2016-04-06 23:31:15 +03:00
const char * reason = NULL ;
2015-10-19 21:58:43 +03:00
int ret ;
2001-10-02 21:09:05 +04:00
2016-06-22 00:24:52 +03:00
if ( arg_is_set ( cmd , cache_long_ARG ) )
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
return _pvscan_cache ( cmd , argc , argv ) ;
2012-02-23 17:11:07 +04:00
2014-03-31 01:32:53 +04:00
if ( argc ) {
log_error ( " Too many parameters on command line. " ) ;
return EINVALID_CMD_LINE ;
}
2016-06-22 00:24:52 +03:00
if ( arg_is_set ( cmd , activate_ARG ) ) {
2012-06-27 17:35:11 +04:00
log_error ( " --activate is only valid with --cache. " ) ;
return EINVALID_CMD_LINE ;
}
2016-06-22 00:24:52 +03:00
if ( arg_is_set ( cmd , major_ARG ) | | arg_is_set ( cmd , minor_ARG ) ) {
2012-03-06 06:30:49 +04:00
log_error ( " --major and --minor are only valid with --cache. " ) ;
return EINVALID_CMD_LINE ;
}
2016-06-22 00:24:52 +03:00
if ( arg_is_set ( cmd , novolumegroup_ARG ) & & arg_is_set ( cmd , exported_ARG ) ) {
2001-10-16 22:07:54 +04:00
log_error ( " Options -e and -n are incompatible " ) ;
2001-10-05 02:53:37 +04:00
return EINVALID_CMD_LINE ;
2001-10-02 21:09:05 +04:00
}
2016-06-22 00:24:52 +03:00
if ( arg_is_set ( cmd , exported_ARG ) | | arg_is_set ( cmd , novolumegroup_ARG ) )
2007-06-28 21:33:44 +04:00
log_warn ( " WARNING: only considering physical volumes %s " ,
2016-06-22 00:24:52 +03:00
arg_is_set ( cmd , exported_ARG ) ?
2001-10-02 21:09:05 +04:00
" of exported volume group(s) " : " in no volume group " ) ;
2016-01-29 01:40:26 +03:00
/* Needed because this command has NO_LVMETAD_AUTOSCAN. */
2016-04-06 23:31:15 +03:00
if ( lvmetad_used ( ) & & ( ! lvmetad_token_matches ( cmd ) | | lvmetad_is_disabled ( cmd , & reason ) ) ) {
pvscan: use process_each_vg for autoactivate
This refactors the code for autoactivation. Previously,
as each PV was found, it would be sent to lvmetad, and
the VG would be autoactivated using a non-standard VG
processing function (the "activation_handler") called via
a function pointer from within the lvmetad notification path.
Now, any scanning that the command needs to do (scanning
only the named device args, or scanning all devices when
there are no args), is done first, before any activation
is attempted. During the scans, the VG names are saved.
After scanning is complete, process_each_vg is used to do
autoactivation of the saved VG names. This makes pvscan
activation much more similar to activation done with
vgchange or lvchange.
The separate autoactivate phase also means that if lvmetad
is disabled (either before or during the scan), the command
can continue with the activation step by simply not using
lvmetad and reverting to disk scanning to do the
activation.
2016-04-28 17:37:03 +03:00
if ( lvmetad_used ( ) & & ! lvmetad_pvscan_all_devs ( cmd , 0 ) ) {
2016-01-29 01:40:26 +03:00
log_warn ( " WARNING: Not using lvmetad because cache update failed. " ) ;
2016-04-14 01:00:01 +03:00
lvmetad_make_unused ( cmd ) ;
2016-01-29 01:40:26 +03:00
}
2016-04-06 23:31:15 +03:00
if ( lvmetad_used ( ) & & lvmetad_is_disabled ( cmd , & reason ) ) {
log_warn ( " WARNING: Not using lvmetad because %s. " , reason ) ;
2016-04-14 01:00:01 +03:00
lvmetad_make_unused ( cmd ) ;
2016-04-06 23:31:15 +03:00
}
2016-01-29 01:40:26 +03:00
}
2013-03-18 00:29:58 +04:00
if ( ! lock_vol ( cmd , VG_GLOBAL , LCK_VG_WRITE , NULL ) ) {
2007-08-23 19:02:26 +04:00
log_error ( " Unable to obtain global lock. " ) ;
return ECMD_FAILED ;
}
2016-05-31 13:24:05 +03:00
if ( ! ( handle = init_processing_handle ( cmd , NULL ) ) ) {
2015-10-19 21:58:43 +03:00
log_error ( " Failed to initialize processing handle. " ) ;
ret = ECMD_FAILED ;
goto out ;
2001-10-02 21:09:05 +04:00
}
2015-10-19 21:58:43 +03:00
handle - > custom_handle = & params ;
2001-10-02 21:09:05 +04:00
2016-02-16 23:15:24 +03:00
ret = process_each_pv ( cmd , argc , argv , NULL , 0 , 0 , handle , _pvscan_single ) ;
2001-10-02 21:09:05 +04:00
2015-10-19 21:58:43 +03:00
if ( ! params . pvs_found )
config: add silent mode
Accept -q as the short form of --quiet.
Suppress non-essential standard output if -q is given twice.
Treat log/silent in lvm.conf as equivalent to -qq.
Review all log_print messages and change some to
log_print_unless_silent.
When silent, the following commands still produce output:
dumpconfig, lvdisplay, lvmdiskscan, lvs, pvck, pvdisplay,
pvs, version, vgcfgrestore -l, vgdisplay, vgs.
[Needs checking.]
Non-essential messages are shifted from log level 4 to log level 5
for syslog and lvm2_log_fn purposes.
2012-08-25 23:35:48 +04:00
log_print_unless_silent ( " No matching physical volumes found " ) ;
2014-03-19 03:19:01 +04:00
else
log_print_unless_silent ( " Total: %d [%s] / in use: %d [%s] / in no VG: %d [%s] " ,
2015-10-19 21:58:43 +03:00
params . pvs_found ,
display_size ( cmd , params . size_total ) ,
params . pvs_found - params . new_pvs_found ,
display_size ( cmd , ( params . size_total - params . size_new ) ) ,
params . new_pvs_found , display_size ( cmd , params . size_new ) ) ;
2001-10-02 21:09:05 +04:00
2015-10-19 21:58:43 +03:00
out :
lvmetad: two phase vg_update
Previously, a command sent lvmetad new VG metadata in vg_commit().
In vg_commit(), devices are suspended, so any memory allocation
done by the command while sending to lvmetad, or by lvmetad while
updating its cache could deadlock if memory reclaim was triggered.
Now lvmetad is updated in unlock_vg(), after devices are resumed.
The new method for updating VG metadata in lvmetad is in two phases:
1. In vg_write(), before devices are suspended, the command sends
lvmetad a short message ("set_vg_info") telling it what the new
VG seqno will be. lvmetad sees that the seqno is newer than
the seqno of its cached VG, so it sets the INVALID flag for the
cached VG. If sending the message to lvmetad fails, the command
fails before the metadata is committed and the change is not made.
If sending the message succeeds, vg_commit() is called.
2. In unlock_vg(), after devices are resumed, the command sends
lvmetad the standard vg_update message with the new metadata.
lvmetad sees that the seqno in the new metadata matches the
seqno it saved from set_vg_info, and knows it has the latest
copy, so it clears the INVALID flag for the cached VG.
If a command fails between 1 and 2 (after committing the VG on disk,
but before sending lvmetad the new metadata), the cached VG retains
the INVALID flag in lvmetad. A subsequent command will read the
cached VG from lvmetad, see the INVALID flag, ignore the cached
copy, read the VG from disk instead, update the lvmetad copy
with the latest copy from disk, (this clears the INVALID flag
in lvmetad), and use the correct VG metadata for the command.
(This INVALID mechanism already existed for use by lvmlockd.)
2016-06-08 22:42:03 +03:00
unlock_vg ( cmd , NULL , VG_GLOBAL ) ;
2016-06-17 14:29:33 +03:00
destroy_processing_handle ( cmd , handle ) ;
2007-08-23 19:02:26 +04:00
2015-10-19 21:58:43 +03:00
return ret ;
2001-10-02 21:09:05 +04:00
}