* Jun'ichi Nomura > 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. If it will make online resizing work, it is a _huge_ improvement. Maybe a --i-know-what-i-am-doing command line option or something like that could be added so that the admin knows he's opening a small window, but it's much better than the current state of affairs where all services has to be brought down and all filesystems unmounted. But as you say, since it doesn't work with 0.4.7 either it might be a problem separate from the no_flush one that keeps it from working too... :-( > 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. Multipathd removes the paths allright, so that's probably the case. I yanked the paths manually with "echo 1 > /sys/block/$dev/device/delete" but I believe the HBA drivers will also remove the devices if an rport times out, so the same will probably happen... This was what was logged: multipathd: sdj: remove path (uevent) multipathd: mysql: load table [0 41943040 multipath 0 1 rdac 2 1 round-robin 0 1 1 8:96 1000 round-robin 0 2 1 8:64 1000 8:112 1000] multipathd: sdg: remove path (uevent) multipathd: mysql: load table [0 41943040 multipath 0 1 rdac 1 1 round-robin 0 2 1 8:64 1000 8:112 1000] I guess that means queue_if_no_path is unreliable with 0.4.7 and earlier. That's good to know, thanks for your insight! Regards -- Tore Anderson -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
