From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 14 18:40:20 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 89DDB16A420; Tue, 14 Feb 2006 18:40:20 +0000 (GMT) (envelope-from tom@uniserve.com) Received: from mx5.uniserve.ca (mx5.uniserve.ca [216.113.192.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E07143D53; Tue, 14 Feb 2006 18:40:18 +0000 (GMT) (envelope-from tom@uniserve.com) Received: from mgmt.uniserve.ca ([216.113.192.30]) by mx5.uniserve.ca with esmtp (Exim 4.50) id 1F9562-000Agl-6W; Tue, 14 Feb 2006 10:40:18 -0800 Date: Tue, 14 Feb 2006 10:40:18 -0800 (PST) From: Tom Samplonius X-X-Sender: tom@mgmt.uniserve.ca To: Gary Palmer In-Reply-To: <20060214150845.GB29569@in-addr.com> Message-ID: <20060214103146.K99735@mgmt.uniserve.ca> References: <2CEE6163475607F32A420FA1@jordgubbe.pingpong.net> <20060207121257.D53605@mgmt.uniserve.ca> <20060214150845.GB29569@in-addr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanner: OK. Scanned. 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 18:40:20 -0000 On Tue, 14 Feb 2006, Gary Palmer wrote: > 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 Yes, trespass support. Some controllers support auto-trespassing, but if the controllers do not have cache consistancy, you should probably make sure auto-trespass is disabled. In manual trespassing, a specific SCSI command needs to be sent to activate the dormant LUN, which is generally vendor specific. > 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. Yes, there are a lot of patches on the net to hack in various kinds of trespass support into Linux for various types of boxes. > 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. I don't think this is a problem with current mid-range stuff. A mirrored write cache is considered a basic feature. Not only does a mirrored write cache protect against controller cache consistancy, it also protects losing the contents of the write cache if a controller fails, which is generally a much bigger problem. > Gary > Tom