From owner-freebsd-geom@FreeBSD.ORG Thu May 10 17:09:52 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8849D1065673 for ; Thu, 10 May 2012 17:09:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 37F448FC14 for ; Thu, 10 May 2012 17:09:52 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1703612qcs.13 for ; Thu, 10 May 2012 10:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VhwdVTShE+qxIHIMky4Zpk0l5ZJl2jG6edDD6jIsB4o=; b=uJ9cDekyH/xFmD75dmKo4qY1hKXE5WhzZYPqqbIWlndmh63i8JU2QPIiyfzQevDfWj Jfh5nmGTeMgAbKCs0uFK49Up5SsUsVDi1wPWhLENRElq8jHTPmIn7zzXCdfEUb0qR8BW br0D9b9EazMyPo6oyZCh5vct3tOp+r1qHaHiokW1ktEnDdWGqIH8quj4ZDOwYpdmwVzP mKKu0BX5Yejq/Zw4Xvb+WJpyorcfO+qtDrSQ+/qOej2L6G9EQo92LECm3rNnlXbsJ8sn hLubeAVQa4QiYjmRAjxN/48EUHCOeinDUONLDohRWiZ4LJ7WBbz1XGOcMVQ47ftO7W07 Omyg== Received: by 10.224.111.8 with SMTP id q8mr12833573qap.55.1336669791516; Thu, 10 May 2012 10:09:51 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([192.75.139.249]) by mx.google.com with ESMTPS id r19sm17394346qae.14.2012.05.10.10.09.50 (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 10:09:50 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FABF653.9030609@FreeBSD.org> Date: Thu, 10 May 2012 20:09:39 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Trent Nelson References: <4FABE1A8.4000609@FreeBSD.org> <7CED0E39-8C64-4AC1-80BA-D6DE9703E022@snakebite.org> In-Reply-To: <7CED0E39-8C64-4AC1-80BA-D6DE9703E022@snakebite.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "mj@feral.com" , "freebsd-geom@FreeBSD.org" Subject: Re: Teaching gmultipath about path cost/priority X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:09:52 -0000 On 10.05.2012 19:36, Trent Nelson wrote: > On Thu, May 10, 2012 at 08:41:28AM -0700, Alexander Motin wrote: >> Hi. >> >> > It'd be ideal if there was a way of teaching gmultipath about a path >> > cost/priority, so that it can make an informed decision about which >> > path to choose a) when first initializing, and b) during failover. >> >> The problem with this is how to store that in metadata. As soon as all >> paths have exactly the same metadata and provider names are not >> mentioned there, separate paths properties are not possible at this moment. > > Good point. In my environment, I use all sorts of convoluted ways > to figure out which /dev/da[n] disk represents the optimal path I > want to use. At the very least, I need to probe things from isp > like port id, wwnn and wwpn. > > It's all very driver/HBA/environment specific. > >> As dirty workaround, you may periodically run some script to enforce >> active path on your specific preference. > > Ah! Yeah, that was another approach I was thinking of suggesting; > an ability to (gracefully) tell gmultipath to start using another > path. Ignore my path cost/priority suggestion and pretend I asked > that instead ;-) > > Extending the example in gmultipath(8): > > # gmultipath label -v FRED /dev/da0 /dev/da2 > # disklabel -Brw /dev/multipath/FRED auto > # newfs /dev/multipath/FREDa > # mount /dev/multipath/FREDa /mnt.... > GEOM_MULTIPATH: adding da0 to Fred/b631385f-c61c-11db-b884-0011116ae789 > GEOM_MULTIPATH: da0 now active path in Fred > GEOM_MULTIPATH: adding da2 to Fred/b631385f-c61c-11db-b884-0011116ae789 > > Something along the lines of: > > + # gmultipath active FRED /dev/da2 > + GEOM_MULTIPATH: da2 now active path in Fred > > ....would be perfect! Don't care what it's called; active, failover, > switch, select, activate. It may be not very convenient, but there is a `gmultipath rotate` command to change active path. I'll look on adding possibility to set specific path. > (I presume gmultipath could affect the path switch in a cleaner fashion > than forcing the disk to fail? i.e. make sure all outstanding I/O is > finished first, etc.) Now path switching doesn't waits for running requests completion. Is it a problem for you? -- Alexander Motin