On 11/02/2015 03:52 PM, Paolo Bonzini wrote: > > > On 02/11/2015 14:56, Hannes Reinecke wrote: >> But then the real question remains: >> >> What is the 'correct' behaviour for ioctls when no path retry >> is active (or when no paths are present)? >> >> Should we start path activation? >> If so, should we wait for path activation to finish, risking udev >> killing the worker for that event (udev has a built-in timeout of >> 120 seconds, which we might easily exceed when we need to activate >> paths for large installations or slow path activation ... just >> thinking of NetApp takeover/giveback cycle)? >> If we're not waiting for path activation, where would be the point >> in starting it, seeing that we're not actually interested in the result? >> And if we shouldn't start a path activation, what is the point of >> having code for it in the first place? > > That's a fair question, and it depends on what said udev worker actually > does. > Point is, we have no idea whatsoever what udev might be doing. And experience shows that while most admins/distros etc have a fair knowledge of writing valid udev rules, more often than not the 'queue_if_no_path' feature from multipath totally escapes them. So we will be finding ourselves in positions where programs from udev rules issue ioctls to devices where queue_if_no_path is active. Plus it's a really daunting task to validate all udev rules to check if any of those programs might issue ioctls and blank them out for the queue_if_no_path case. I did a review once for SUSE, but even that might be obsoleted now as rules are being changed all the time. > In any case, if we don't start path activation we should return > ENOTCONN, not ENOTTY. > No problem with that. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
