From owner-freebsd-current@FreeBSD.ORG Fri May 27 19:41:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD6E716A41C for ; Fri, 27 May 2005 19:41:22 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3287C43D1F for ; Fri, 27 May 2005 19:41:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail01.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j4RJfKqK013473 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 28 May 2005 05:41:20 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j4RJfKRx022412; Sat, 28 May 2005 05:41:20 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j4RJfJ3j022411; Sat, 28 May 2005 05:41:19 +1000 (EST) (envelope-from pjeremy) Date: Sat, 28 May 2005 05:41:19 +1000 From: Peter Jeremy To: Charles Swiger Message-ID: <20050527194119.GB18914@cirb503493.alcatel.com.au> References: <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050526235852.M54386@lexi.siliconlandmark.com> <42969C1B.5010301@samsco.org> <20050527092544.GB18696@cirb503493.alcatel.com.au> <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> User-Agent: Mutt/1.4.2i Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 19:41:22 -0000 On Fri, 2005-May-27 13:09:11 -0400, Charles Swiger wrote: >Apple's Xsan clustering solution relies on a so-called "metadata >controller", which keeps track of locking and provides syncronization >and invalidation notification when the filesystem metadata changes. >SAN clients still read the actual file data directly via fibre >channel, but they also need IP-level connectivity via ethernet (an >unroutable LAN is fine) to the MDC. This is roughly the same as AdvFS on the la[te]st version of Tru64 clustering. Both Tru64 and Solaris _require_ a cluster-private LAN (or equivalent - there's a PCI memory-to-memory card that can be used as an alternative). I suspect a master metadata manager and coherency controller with all the other systems as clients is probably the optimal solution. A distributed MESI-style approach would look cleaner but be much more effort to implement and I suspect the inter-node traffic requirements would kill scalability. >The MDC is not a single-point-of-failure since redundant MDC's can be >set up, but I believe if all MDCs go down, Presumably there's MDC failover as part of the cluster management. (At least that's the way that Solaris and Tru64 work). Any UFS guru's want to comment on the [im]practicality of clustering UFS? -- Peter Jeremy