Re: ETCP Project

[David Brower <David.Brower@oracle.com>]

It's still dangerous, because you don't have anything forcing one
node to be passive, just convention and wishful thinking.  That is,
the 'mirror' FS is mounted and active on the second machine.  There's
nothing to keep it from writing.

If this is all you're doing, you might just as well use a
logical volume with a remote block device as the mirror without
the hassle of writing a whole new FS layer.  If you care about your
data integrity, the active first node is fsyncing data that it cares about,
and this flushes through both the local disk and the remote mirror.  If
it isn't fsyincing, remoting the write(2) call could have the curious semantic
of the data getting flushed to the disk on the remote node, but still
lying around the cache of the local node.  That could be confusing.

-dB

Greg Lindahl wrote:

> On Thu, Mar 01, 2001 at 05:58:27PM -0800, David Brower wrote:
>
> > The big problem case to work out is:  processes on each node
> > writing to the end of a log file.  You must get all lines from all processes
> > in correct time order, without losing anything.  This is a highly contended
> > block
> > with concurrent writes, followed by file extension.
>
> I'm afraid you've mistaken what I suggested for something which allows
> concurrent access. It doesn't. One server is active, the other is
> passive. It's exactly the same as drbd, only one level higher in the
> OS: VFS layer instead of block device layer.
>
> -- g
>
> Linux-cluster: generic cluster infrastructure for Linux
> Archive:       http://mail.nl.linux.org/linux-cluster/


Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/