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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel