From: Richard Weinberger <richard@nod.at>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Do not check ocfs2
Date: Sun, 3 Mar 2013 10:02:54 +0100 [thread overview]
Message-ID: <20130303100254.500b076f@spider.haslach.nod.at> (raw)
In-Reply-To: <20130303011917.GI23616@dastard>
Am Sun, 3 Mar 2013 12:19:17 +1100
schrieb Dave Chinner <david@fromorbit.com>:
> On Sun, Mar 03, 2013 at 01:05:50AM +0100, Richard Weinberger wrote:
> > We cannot run fsck.ocfs2 because the file system
> > is most likely mounted on another node.
>
> This patch means that ocfs2 filesystems are *never* checked for
> consistency, even when you are testing them with exclusive local
> access. That defeats a primary function of xfstests - ensuring that
> the tests run do no corrupt the filesystem.
>
> Besides, why would you be running xfstests on a filesystem that is
> mounted on multiple nodes? Yes, ocfs2 is a cluster filesystem, but
> xfstests is designed to test local filesystem behaviour and is
> completely cluster naive. Hence having multiple nodes mount the
> filesystem that is being tested by xfstests does not serve any
> purpose at all. Further, turning off consistency checking for those
> that are running ocfs2 testing on single nodes means that testing is
> now mostly wasted as the majority of problems that can occur are no
> longer detectable....
Using xfstests I was able to trigger dlm issues in ocfs2.
I ran xfstests on one node and other nodes had it mounted too.
To ensure that fsck.ocfs2 will not corrupt the filesystem I've applied
this patch.
If you don't like the patch I'm perfectly fine with that.
Maybe it makes more sense to add a feature to xfstests which unmounts
the ocfs2 filesystem on all nodes (using SSH), then it is allowed to
run fsck.ocfs2.
Thanks,
//richard
next prev parent reply other threads:[~2013-03-03 9:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-03 0:05 [PATCH] Do not check ocfs2 Richard Weinberger
2013-03-03 1:19 ` Dave Chinner
2013-03-03 9:02 ` Richard Weinberger [this message]
2013-03-03 22:04 ` Eric Sandeen
2013-03-03 22:19 ` Richard Weinberger
2013-03-03 22:40 ` Eric Sandeen
2013-03-03 22:53 ` Richard Weinberger
2013-03-03 22:57 ` Eric Sandeen
2013-03-04 0:42 ` Dave Chinner
2013-03-04 21:05 ` Joel Becker
2013-03-04 22:09 ` Richard Weinberger
2013-03-04 22:57 ` Joel Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130303100254.500b076f@spider.haslach.nod.at \
--to=richard@nod.at \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).