All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Richard Weinberger <richard@nod.at>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] Do not check ocfs2
Date: Sun, 03 Mar 2013 16:04:48 -0600	[thread overview]
Message-ID: <5133C900.9050300@sandeen.net> (raw)
In-Reply-To: <20130303100254.500b076f@spider.haslach.nod.at>

On 3/3/13 3:02 AM, Richard Weinberger wrote:
> 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.

Just for my own education, how does that happen?

Were you testing on filesystems already configured into a cluster,
or did the cluster somehow pick up your newly-defined test
fileystems and mount them?

How does fsck.ocfs2 behave when you run it on one node, when the
fs is mounted on others?  Will it proceed w/ no knowledge of the
fact that it's mounted elsewhere?

-Eric

> 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
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-03-03 22:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-03  0:05 [PATCH] Do not check ocfs2 Richard Weinberger
2013-03-03  0:05 ` Richard Weinberger
2013-03-03  1:19 ` Dave Chinner
2013-03-03  1:19   ` Dave Chinner
2013-03-03  9:02   ` Richard Weinberger
2013-03-03  9:02     ` Richard Weinberger
2013-03-03 22:04     ` Eric Sandeen [this message]
2013-03-03 22:19       ` Richard Weinberger
2013-03-03 22:19         ` Richard Weinberger
2013-03-03 22:40         ` Eric Sandeen
2013-03-03 22:40           ` Eric Sandeen
2013-03-03 22:53           ` Richard Weinberger
2013-03-03 22:53             ` Richard Weinberger
2013-03-03 22:57             ` Eric Sandeen
2013-03-03 22:57               ` Eric Sandeen
2013-03-04  0:42               ` Dave Chinner
2013-03-04  0:42                 ` Dave Chinner
2013-03-04 21:05                 ` Joel Becker
2013-03-04 21:05                   ` Joel Becker
2013-03-04 22:09                   ` Richard Weinberger
2013-03-04 22:09                     ` Richard Weinberger
2013-03-04 22:57                     ` Joel Becker
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=5133C900.9050300@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=richard@nod.at \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.