From owner-freebsd-current@FreeBSD.ORG Sat May 28 16:36:55 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 78D2B16A421 for ; Sat, 28 May 2005 16:36:55 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (tourist.net8.nerim.net [213.41.176.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0674F43E49 for ; Sat, 28 May 2005 16:04:46 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (localhost [127.0.0.1]) by sockar.homeip.net (8.13.3/8.13.3) with ESMTP id j4SG4eKP024976 for ; Sat, 28 May 2005 18:04:40 +0200 (CEST) (envelope-from amon@sockar.homeip.net) Received: (from amon@localhost) by sockar.homeip.net (8.13.3/8.13.3/Submit) id j4SG4dh6024975 for freebsd-current@freebsd.org; Sat, 28 May 2005 18:04:39 +0200 (CEST) (envelope-from amon) Date: Sat, 28 May 2005 18:04:39 +0200 From: Herve Boulouis To: freebsd-current@freebsd.org Message-ID: <20050528160439.GA81706@ra.aabs> 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=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> User-Agent: Mutt/1.4.2.1i 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: Sat, 28 May 2005 16:36:55 -0000 Le 27/05/2005 13:09, Charles Swiger a écrit: > > >Solaris clustering routes all I/O to a shared filesystem to a single > >'master' node, which is responsible for all physical I/O to the disk. > >This would significantly simplify cache coherency management. > > 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. SGI's CXFS works exactly the same way. The metadata server (one per filesystem) is accessed through an ip network and data are accessed through the SAN. I suppose that the journaling capabilities of XFS are used to do the metadata server's work but I'm not sure. -- Herve Boulouis