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