From owner-freebsd-scsi@FreeBSD.ORG Mon Feb 20 17:20:09 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 21CAB16A420; Mon, 20 Feb 2006 17:20:09 +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 B596043D46; Mon, 20 Feb 2006 17:20:08 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from uucp by noop.colo.erols.net with local-rmail (Exim 4.52 (FreeBSD)) id 1FBEhj-000MP4-VN; Mon, 20 Feb 2006 12:20:07 -0500 Received: from localhost.home.in-addr.com ([127.0.0.1]:60714) by rimmer.home.in-addr.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBEYF-000EsI-CZ; Mon, 20 Feb 2006 17:10:19 +0000 Message-ID: <43F9F7FB.1000805@freebsd.org> Date: Mon, 20 Feb 2006 17:10:19 +0000 From: Gary Palmer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060203 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Joao Barros References: <2CEE6163475607F32A420FA1@jordgubbe.pingpong.net> <20060207121257.D53605@mgmt.uniserve.ca> <20060214150845.GB29569@in-addr.com> <20060214103146.K99735@mgmt.uniserve.ca> <70e8236f0602161437o1593c147na97239cf9054610e@mail.gmail.com> In-Reply-To: <70e8236f0602161437o1593c147na97239cf9054610e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Mon, 20 Feb 2006 17:20:09 -0000 Joao Barros wrote: >On 2/14/06, Tom Samplonius wrote: > > >>On Tue, 14 Feb 2006, Gary Palmer wrote: >> >> >> >>>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. >> >> > >The EMC Clarion Series, at least the CX600 model I work with has >mirrored write cache. >In the event of controller failure it is disabled until redundancy is restored. >I had training on an entry level model, a CX300 and the funcionality >was the same. > >The Symetrix I bet it has but EMC doesn't let us touch those ;-) > > I know of at least 2 arrays from one manufacturer (which I suspect were actaully the same controller "heads" just with different numbers of drive trays and/or drive busses supported) which were aimed at the midrange "class" and did NOT support writing to the same LUN through different controllers. The controllers took the LUN offline for a while (measured in seconds, from memory) to hand off the LUN from one controller (the "owner") to the other (the one that had received the last write). This played havoc with systems who weren't using the vendor-supplied drivers, which we suspect were just delaying and retrying I/Os until the LUN came back. Maybe mirrored write cache isn't enough and there are other firmware things that are needed for this to work properly. The Symetrix should be fine as it, at least the last time I got a preso from EMC, has one cache shared amongst the host controllers. But if you are expecting to be able to write to a LUN through any controller, then its worth testing that the array doesn't have pathological behaviour. After the stuff I've seen, I can't make the assumption that it'll just work anymore.