Re: Resizing multipath maps: reload ioctl failed: Invalid argument

["Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>]

Hi,

Tore Anderson wrote:
>> It's due to kernel device-mapper restriction.
>>
>> multipath-tools uses no_flush suspend of device-mapper device to save
>> I/O errors in all-paths-down case. (Without the option, device-mapper
>> needs to flush all pending I/Os, that will result in I/O errors if
>> there is no working path.)
>>
>> For no_flush suspend, resizing is disabled because of known
>> dead-lock: it requires a lock that can be kept hold until the pending
>> I/Os are flushed.
> 
>   Hmm.  So this deadlock is a kernel bug that (hopefully) will be fixed
>  in the future, so resizing can again be enabled, or is this a design
>  limitation that it's impossible to do something about?

IMO, it's not a design limitation and should be solved in future.

>   Can the no_flush thing be toggled online;  that is, would it be
>  possible to alter multipath-tools so that when it attempted to resize a
>  map, it would disable no_flush, resize it, and then re-enable it?  I
>  think a two-second window of vulnerability to all-paths-down is
>  acceptable...

Everywhen you suspend the device, there is a possibility of
all paths being down. So as far as you don't want to lose data,
you have to use no_flush option.

>   Similarily, if this no_flush option is relevant only when
>  features=queue_if_no_paths (at least that's the impression I get from
>  your description of it), would it work to temporarily reload the map
>  without this feature, resize the volume, than re-add queue_if_no_path?

Current code uses 'no_flush' unconditionally.
I think it's possible to improve it to do that only when
queue_if_no_path is enabled.

>> A workaround for it would be using modified multipath-tools which
>> doesn't use no_noflush.
> 
>   I grepped for noflush and no_flush (and so on) in the multipath-tools
>  source code but can't really find where it is set..?

Hmm, sorry. I misread your first message.
Since the feature is added after 0.4.7, your problem may be caused
by other reason.
The call to dm_task_no_flush() is added after the release of 0.4.7.
It should be in dm_simplecmd() in libmultipath/devmapper.c.

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America