[dm-devel] Resizing multipath maps: reload ioctl failed: Invalid argument
Jun'ichi Nomura
j-nomura at ce.jp.nec.com
Mon Aug 27 22:44:12 UTC 2007
Hi,
Tore Anderson wrote:
>> 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.
>
> It certainly would be an improvement if no_flush and queue_if_no_path
> could be automatically disabled in the short time it will take to
> reload the multipath map with an increased size. For extra safety the
> tool could also verify that no paths were failed before doing so,
> maybe. If everything is working fine it seems rather unlikely that all
> paths will fail and all HBA driver timeouts will expire in the second
> it takes to reload the multipath map.
It's not good to override a policy about queue_if_no_path, that will
create a small window of data loss.
Even the small window could result in a disaster.
I meant in the previous mail that there is no need for multipath-tools
to use no_flush if a user explicitly configures the device without
queue_if_no_path.
Assuming that users sensitive to the system availability would set
queue_if_no_path, I'm not sure how useful the improvement is.
>> 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.
>
> Interesting. I sent an email titled "dm-rdac not working?" earlier
> today, where I described another problem with the RDAC hwhandler that
> also caused I/O errors to propagate up from device-mapper into VFS,
> even though queue_if_no_path was in use. Is it possible, you think,
> that this misbehaviour was due to having loaded the multipath maps
> using 0.4.7 and therefore without no_flush being set? (Or in other
> words: Is 0.4.8 a requirement for queue_if_no_path to work correctly?)
As far as the table is not suspended, e.g. just failing or reinstating
paths, queue_if_no_path works correctly without no_flush.
When the table is suspended, e.g. a path is added or removed, pending
I/Os will be flushed on suspend even if queue_if_no_path is specified.
That's the situation no_flush solves.
Easiest check is perhaps stracing multipath/multipathd and see what
ioctls they issue. If they do DM_DEV_SUSPEND, using 0.4.8 might be a
solution. If they don't, the cause is in other place.
Thanks,
--
Jun'ichi Nomura, NEC Corporation of America
More information about the dm-devel
mailing list