From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe Varoqui Subject: Re: path group failback Date: Mon, 13 Mar 2006 18:17:35 +0100 Message-ID: <20060313171735.GA13642@pundit> References: Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: egoggin@emc.com Cc: dm-devel@redhat.com, christophe.varoqui@free.fr List-Id: dm-devel.ids > > In such a scenario, wouldn't the priorizer catch priority changes ? > > No, not necessarily, and certainly not for CLARiiON. None of these > 3 use cases involves changing which path group is the highest priority > path group so each path in the 2 groups continue to have the same > priority as before the externally initiated change of the active path > group. For each use case, only the identity of the active path group > has been changed. > I guess the priorizer *should* catch priority changes ... > > > > ie, paths to owning SP are heavier than paths to not owning SP, so > > changing the owning SP in navisphere would shuffle the path group > > priorites. > > CLARiiON path priority is dependent solely on 2 factors -- (1) the > path must be active (or ghost) and (2) the path must connect to its > logical unit's "default" (not necessarily active) owning service > processor. > > > > > If it is the case I would imagine the failback target to be the > > externally designated one, which seems right. > > No. The CLARiiON's highest priority path group is defined to be > the default owning service processor instead of the active service > processor (they may or may not be the same at any given instant) > in order to maintain the manually established distribution of > logical units across the 2 service processors. > Would it be unreasonable to teach the prioritizer about this case ? Regards, cvaroqui