Date: Tue, 14 Feb 2006 10:40:18 -0800 (PST) From: Tom Samplonius <tom@uniserve.com> To: Gary Palmer <gpalmer@freebsd.org> Cc: Palle Girgensohn <girgen@FreeBSD.org>, scsi@FreeBSD.org Subject: Re: NAS w/ multipath Message-ID: <20060214103146.K99735@mgmt.uniserve.ca> In-Reply-To: <20060214150845.GB29569@in-addr.com> References: <2CEE6163475607F32A420FA1@jordgubbe.pingpong.net> <20060207121257.D53605@mgmt.uniserve.ca> <20060214150845.GB29569@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060214103146.K99735>