[dm-devel] Resizing multipath maps: reload ioctl failed: Invalid argument
Jun'ichi Nomura
j-nomura at ce.jp.nec.com
Mon Aug 27 20:29:46 UTC 2007
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
More information about the dm-devel
mailing list