From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 14 15:08:46 2006 Return-Path: X-Original-To: scsi@FreeBSD.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA24F16A423; Tue, 14 Feb 2006 15:08:46 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ACC743D5D; Tue, 14 Feb 2006 15:08:45 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.colo.erols.net with local (Exim 4.52 (FreeBSD)) id 1F91nJ-0003Fm-4U; Tue, 14 Feb 2006 10:08:45 -0500 Date: Tue, 14 Feb 2006 10:08:45 -0500 From: Gary Palmer To: Tom Samplonius Message-ID: <20060214150845.GB29569@in-addr.com> References: <2CEE6163475607F32A420FA1@jordgubbe.pingpong.net> <20060207121257.D53605@mgmt.uniserve.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060207121257.D53605@mgmt.uniserve.ca> Cc: Palle Girgensohn , scsi@FreeBSD.org Subject: Re: NAS w/ multipath X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 15:08:47 -0000 On Tue, Feb 07, 2006 at 12:22:33PM -0800, Tom Samplonius wrote: > Now, in FreeBSD you could also multipath in the GEOM layer. GEOM knows > about devices going away, and knows how to handle that (ex. gmirror). > There is some support in GEOM for round-robin IO to two devices. However, > phk has reported that the isp driver can hang forever on some timeouts, so > it might not be useful. And I don't even know if GEOM round-robin is even > finished. Be very careful with that kind of work. There are SAN units out there that do not share caches across multiple controllers. To work around that limitation, they have one controller than can "own" the LUN at any one time, to ensure data consistency. So if you write to a LUN through the controller which does not "own" the LUN, it actually transfers "ownership" of the LUN to the controller you sent the request through. In at least one implimentation, the LUN vanishes from both controllers for a period measured in seconds while management of the LUN is handed off from one controller to the other. The vendor worked around this with special drivers that lived on the OS, which wasn't an option for us as they didn't have FreeBSD support. I suspect higher end devices (e.g. HDS and EMC Symmetrix units) this isn't a problem, but in mid range and lower end stuff I'd expect problems if the paths landed on separate controllers on the array. Gary