From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 9 13:59:12 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4296D1B9 for ; Tue, 9 Dec 2014 13:59:12 +0000 (UTC) Received: from rack.patpro.net (rack.patpro.net [193.30.227.216]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "patpro.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4C9787E for ; Tue, 9 Dec 2014 13:59:11 +0000 (UTC) Received: from patpro.univ-lyon2.fr (patpro.univ-lyon2.fr [159.84.113.250]) by rack.patpro.net (Postfix) with ESMTPSA id AA747DC0; Tue, 9 Dec 2014 14:59:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=patpro.net; s=patpro; t=1418133543; bh=t6WsvQFhotEBLIgMvMQ2Bd9ATyw0UgSYljZ7T0SUiHU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=IxoEAoMxpuNsOy8jl33Apl1me6wJR87m80956J6LVcclD/JCY7kE3keLWylzz6Yfr 7PBNo6Jj0DbMazUqRRr4EudgbT3vc+Uk3KmaL+MQi+j8iLUm4z7c0B4olk8mmkQvVh 38j6AJsa6HMwtGxZh2vX2Nuu4Q6s/qZZwG7QLt38= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: multipath problem: active provider chosen on passive FC path? From: patpro@patpro.net In-Reply-To: Date: Tue, 9 Dec 2014 14:59:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23F06C2E-558A-4E68-AD35-B3CD49760DFE@patpro.net> <81548287-A118-4AFD-8AB5-F76CD3B060FF@samplonius.org> To: "freebsd-scsi@freebsd.org" X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 13:59:12 -0000 On 8 d=E9c. 2014, at 22:33, Patrick Proniewski = wrote: >> FC switches are typically active-active, as the FC switch fabric is = "intelligent" and doesn't have looping issues like ethernet. >>=20 >> Your issue is probably on the storage array. Storage arrays = typically have an OS profile, and various advanced settings for how a = LUN is exported to a client. Storage arrays typically support SCSI = Reservations, where the LUN must be reserved before it can be used. = Also, storage arrays typically have multiple controller cards, and = typically an LUN is owned by one of the controllers at a time. The = storage array can signal to the client via SCSI that it wants to move = the the ownership to another controller. With proper client support, = migrating a LUN to another controller is typically hit-less.=20 >>=20 >> In your case, the storage array is probably configured to use one = controller/path at a time. And it is probably expecting to see specific = SCSI messages between itself and the host. These type of settings are = typically set by the OS profile. >>=20 >> Generally, storage arrays work best if you only send IO to one = controller at a time. And this involves co-ordination between the array = and the client using SCSI control messages. Though active-active paths = can usually be supported as well. >=20 >=20 > Thank you for your reply. The SAN is an EMC VNX 5300. By default it = presents LUNs using ALUA as failover mechanism. I though GEOM could not = handle ALUA properly, so I changed the failover setting for this LUN, = now the FreeBSD hang during boot. If I boot in single user mode, it = boots completely but the result is the same default active path is not = functioning correctly. >=20 > Tomorrow, I'll try another failover setting (dubbed "legacy"). The SAN = also allows me to specify initiator type (default to Clariion), I'll dig = into this setting to see if something exists that is more adapted to = FreeBSD host. Ok, I've tried a lot of things, but the problem is the same: I can = create a gmultipath device, play with it, but it will always have very = poor performances until providers are marked "FAIL". Eventually it ends with this kind of situation: # gmultipath status Name Status Components multipath/SPLUNK_2 DEGRADED da3 (PASSIVE) da7 (FAIL) da2 (ACTIVE) da6 (FAIL) If I play with every settings, I can come up with more than 70 = combinations. Far more than I can afford to test, unfortunately. Unless = a clever solution exists that I don't know yet, I'll have to give up on = FreeBSD for this project. I've asked EMC for support. Let's hope it does not end with a "not in = compatibility matrix" answer. Any help still appreciated... Patrick