On 25.04.2016 18:00, dm-devel-request@xxxxxxxxxx wrote: > Date: Mon, 25 Apr 2016 09:49:50 +0200 From: Hannes Reinecke > <hare@xxxxxxx> To: dm-devel@xxxxxxxxxx Subject: Re: Upcall > prioritizer for multipath Message-ID: <571DCC1E.5000908@xxxxxxx> > Content-Type: text/plain; charset=windows-1252 > Ah, the good old days. You do remember (of course, as you as a > diligent developer would have had a look through the archives, right?) > that we original did precisely that, namely using 'prio' as an > external callout. The reason why we moved away from this is a > deadlock: When all paths are down (ie the _one_ situation where you > absolutely _need_ multipath to work) you cannot reinstate any paths, > as for reinstating you would need to call the prio program. Which > happens to be an external program, which would need to be loaded from > disk. Which is not available. Say goodbye to your machine :-( So we've > moved to using a shared library mechanism, which can be mlock()ed at > boot to avoid these situations. Hence I would really _not_ use this > approach. Thanks for your explanation. In fact I missed that discussion from 2007 when searching the archive. Of course your point is valid, but it doesn't apply to my use case of a storage server, where multipath isn't used at all for the system disk. Can't say I know the perfect solution, but as a user I still would like to point out, that handling JBODs (where you don't have stable WWIDs) is awkward with multipathd (as is), where everything is so static. An alternative that should be safe from the mentioned deadlock (as I understand it) would be to create a prioritizer that reads the prio from an udev attribute. Then the callout can be done from an udev rule. This would fix my problem fine, but the disadvantage is of course, that it could not be used for dynamically changing path priorities, as udev won't reevaluate the rule periodically. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
