Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 May 2005 13:09:11 -0400
From:      Charles Swiger <cswiger@mac.com>
To:        Peter Jeremy <PeterJeremy@optushome.com.au>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: Disable read/write caching to disk?
Message-ID:  <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com>
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> <A70C5E4F-D9F9-4756-8AC2-591462E338DE@shire.net> <4296997C.9030700@samsco.org> <20050526235852.M54386@lexi.siliconlandmark.com> <42969C1B.5010301@samsco.org> <20050527092544.GB18696@cirb503493.alcatel.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C7F0B94-4D12-41A3-9A61-C3B620804671>