From owner-freebsd-current@FreeBSD.ORG Fri May 27 17:09: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 4D0BE16A41C for ; Fri, 27 May 2005 17:09:22 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1681643D1D for ; Fri, 27 May 2005 17:09:22 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout10/MantshX 4.0) with ESMTP id j4RH9KXI013154; Fri, 27 May 2005 10:09:20 -0700 (PDT) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j4RH9GWe000783; Fri, 27 May 2005 10:09:17 -0700 (PDT) In-Reply-To: <20050527092544.GB18696@cirb503493.alcatel.com.au> References: <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <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> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Fri, 27 May 2005 13:09:11 -0400 To: Peter Jeremy X-Mailer: Apple Mail (2.730) 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 17:09:22 -0000 On May 27, 2005, at 5:25 AM, Peter Jeremy wrote: > On Thu, 2005-May-26 22:03:39 -0600, Scott Long wrote: >> A few people have suggested modifying UFS to fill this role. It >> probably >> is just as much work as porting GFS, if not more, since UFS/FFS is >> closely tied to the buffer cache and block layers on BSD, and >> divorcing >> probably would be quite difficult. >> > > It's probably worth noting that (AFAIK) none of the commercial vendors > have managed to build a multi-master shared UFS filesystem. This > suggests that the effort is considerable. I would agree with this observation. :-) > 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. 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, the clients are restricted to read & modify operations only to open files they'd already been using. -- -Chuck