Re: how to prevent filesystem check

[Andreas Dilger <adilger clusterfs com>]

On Nov 29, 2006  09:02 -0500, Theodore Tso wrote:
> On Tue, Nov 28, 2006 at 09:20:26PM -0800, Andreas Dilger wrote:
> > This is a good reason for the multi-mount protection feature that I
> > proposed previously.  It would mark the filesystem as in-use on one 
> > node and the filesystem itself would refuse to mount on the second
> > node.  Unfortunately, this idea met resistance from some of the
> > other ext3 developers from merging it upstream.
> 
> The resistance was because it means we have to put what is effectively
> a cluster filesystem's distributed lock manager (DLM) just to tell
> users that "News flash!  ext3 isn't a cluster filesystem" and then
> error-out the mount.  Granted, it was a relatively simple cluster DLM,
> but that's what you effectively need, complete with issues surrounding
> heartbeats for liveness detection --- and since it was a simple
> cluster DLM, it didn't handle temporary connectivity failure since
> there was no STONITH (shoot-the-other-node-in-the-head) functionality.
> So it didn't even solve the problem completely.

I agree that the proposed MMP code is by no means a 100% solution, and
is not intended to replace HA + STONITH.  Rather, it is intended to
handle the "oops, HA is broken, admin set it up incorrectly, FC routing
broke, SCSI devices were renamed, etc" kind of issues.

> Still, if a lot of users are making this fundamental mistake of trying
> to use ext3 as a cluster filesystem, maybe we need to revisit this
> question, since hopefully once the user sees the error message they
> won't keep doing this.

The only reason I raised this again was because this "mount ext2/3 on
two nodes, one being read-only" is a fairly common thing for users to
try and it really deserves some kind of attention.  The ability to
have multi-host block devices is only increasing I think, especially
in server-type environments with FC, IB, ISCSI, etc.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.