[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ETCP Project
On Thu, Mar 01, 2001 at 06:18:46PM -0800, David Brower wrote:
> 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.
What makes you think that? Yes, this is a concern, but there are
technical ways to ensure that. The underlying FS can sit on a path
that the user-level daemon opens and then chmods one of the elements
to something such that no one else can go there.
> 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.
My first posting listed some advantages and disadvantages of that
approach, namely that with a block device such as drbd you have to
fsck if there's a failure or use a journaled filesystem. A second
advantage/problem is that block devices may very well transfer more
data for certain access patterns (1 block minimum transfer), but of
course they can use caching but the VFS layer goober can't.
> 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.
My VFS layer can fsync on behalf of the program after any write. Of
course the semantics of filesystem metadata getting written to disk
are interesting, but I suspect I'd be doing journaling in my VFS layer
anyway. Other manifestations of PVFS (the single-metadata-controller
parallel filesystem manifestation) need journaling anyway.
-- g
Linux-cluster: generic cluster infrastructure for Linux
Archive: http://mail.nl.linux.org/linux-cluster/