[PATCH] Do not check ocfs2

[PATCH] Do not check ocfs2

[Richard Weinberger]

We cannot run fsck.ocfs2 because the file system
is most likely mounted on another node.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 common.rc | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/common.rc b/common.rc
index f5180fe..00c075d 100644
--- a/common.rc
+++ b/common.rc
@@ -1419,6 +1419,9 @@ _check_test_fs()
     udf)
 	# do nothing for now
 	;;
+    ocfs2)
+	# other nodes may have mounted the fs
+	;;
     btrfs)
 	_check_btrfs_filesystem $TEST_DEV
 	;;
@@ -1448,6 +1451,9 @@ _check_scratch_fs()
     nfs*)
 	# Don't know how to check an NFS filesystem, yet.
 	;;
+    ocfs2)
+	# other nodes may have mounted the fs
+	;;
     btrfs)
 	_check_btrfs_filesystem $SCRATCH_DEV
 	;;
-- 
1.8.1.2

[PATCH] Do not check ocfs2

[Richard Weinberger]

We cannot run fsck.ocfs2 because the file system
is most likely mounted on another node.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 common.rc | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/common.rc b/common.rc
index f5180fe..00c075d 100644
--- a/common.rc
+++ b/common.rc
@@ -1419,6 +1419,9 @@ _check_test_fs()
     udf)
 	# do nothing for now
 	;;
+    ocfs2)
+	# other nodes may have mounted the fs
+	;;
     btrfs)
 	_check_btrfs_filesystem $TEST_DEV
 	;;
@@ -1448,6 +1451,9 @@ _check_scratch_fs()
     nfs*)
 	# Don't know how to check an NFS filesystem, yet.
 	;;
+    ocfs2)
+	# other nodes may have mounted the fs
+	;;
     btrfs)
 	_check_btrfs_filesystem $SCRATCH_DEV
 	;;
-- 
1.8.1.2

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

Re: [PATCH] Do not check ocfs2

[Dave Chinner]

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....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [PATCH] Do not check ocfs2

[Dave Chinner]

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....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: [PATCH] Do not check ocfs2

[Richard Weinberger]

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

Re: [PATCH] Do not check ocfs2

[Richard Weinberger]

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

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

Re: [PATCH] Do not check ocfs2

[Eric Sandeen]

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

Re: [PATCH] Do not check ocfs2

[Richard Weinberger]

Am Sun, 03 Mar 2013 16:04:48 -0600
schrieb Eric Sandeen <sandeen@sandeen.net>:
 > > 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?

The cluster is already configured. But a single node can mount/unmount
the fs as it wants.

I know, xfstests is not a perfect test case for ocfs2 but it allowed me
to trigger issues...
These issues can also be triggered without xfstests. But in my case I
found them using xfstests.

> 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?

It refuses to check the fs and exists with an error code != 0.

>From the manpage:
       -F     By default fsck.ocfs2 will check with the cluster
services to ensure that the volume is not in-use (mounted) on any node
in the cluster before proceeding.  -F skips this check and should only
be used when it can be guaranteed that the volume is not mounted on any
node in the cluster. WARNING: If the cluster check is disabled and the
volume  is mounted on one or more nodes, file system corruption is very
likely. If unsure, do not use this option.

Thanks,
//richard

Re: [PATCH] Do not check ocfs2

[Richard Weinberger]

Am Sun, 03 Mar 2013 16:04:48 -0600
schrieb Eric Sandeen <sandeen@sandeen.net>:
 > > 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?

The cluster is already configured. But a single node can mount/unmount
the fs as it wants.

I know, xfstests is not a perfect test case for ocfs2 but it allowed me
to trigger issues...
These issues can also be triggered without xfstests. But in my case I
found them using xfstests.

> 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?

It refuses to check the fs and exists with an error code != 0.

>From the manpage:
       -F     By default fsck.ocfs2 will check with the cluster
services to ensure that the volume is not in-use (mounted) on any node
in the cluster before proceeding.  -F skips this check and should only
be used when it can be guaranteed that the volume is not mounted on any
node in the cluster. WARNING: If the cluster check is disabled and the
volume  is mounted on one or more nodes, file system corruption is very
likely. If unsure, do not use this option.

Thanks,
//richard

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

Re: [PATCH] Do not check ocfs2

[Eric Sandeen]

On 3/3/13 4:19 PM, Richard Weinberger wrote:
> Am Sun, 03 Mar 2013 16:04:48 -0600
> schrieb Eric Sandeen <sandeen@sandeen.net>:
>  > > 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?
> 
> The cluster is already configured. But a single node can mount/unmount
> the fs as it wants.

Ok, so:
a) your cluster is already configured, and 
b) other nodes can mount cluster filesystems

Sure, but - how *did* other nodes mount your xfstest filesystems?
Or did you configure xfstests to use something already configured
to be mounted on multiple nodes?

Perhaps another related question - did the fs *need* to be mounted
on other nodes to expose the problems you found?

I'm just trying to understand if this is a common case, or unique to
how you have configured things.

> I know, xfstests is not a perfect test case for ocfs2 but it allowed me
> to trigger issues...
> These issues can also be triggered without xfstests. But in my case I
> found them using xfstests.

I understand, I'm not suggesting that you not run xfstests; I'm sure
it is useful.  It's supposed to be.  :)  We just need to keep it
useful & not disable the consistency checks unless it's necessary.

>> 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?
> 
> It refuses to check the fs and exists with an error code != 0.

Ok, then that confuses me a little, because earlier you said:

> To ensure that fsck.ocfs2 will not corrupt the filesystem 

but just now you said it won't run at all?  Anyway...

> From the manpage:
>        -F     By default fsck.ocfs2 will check with the cluster
> services to ensure that the volume is not in-use (mounted) on any node
> in the cluster before proceeding.  -F skips this check and should only
> be used when it can be guaranteed that the volume is not mounted on any
> node in the cluster. WARNING: If the cluster check is disabled and the
> volume  is mounted on one or more nodes, file system corruption is very
> likely. If unsure, do not use this option.

Ok, but xfstests wasn't *using* -F was it?

Anyway, what if you did something more along the lines of [pseudocode]

ocfs2)
	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
		;
	else
		fsck.ocfs2 $TEST-DEV
	fi
	;;

so that *if* it's mounted on some other node, the fsck won't run.
That has downsides as Dave mentioned, but for the case where the
xfstests node is the only one with it in use, it'll still do the
beneficial consistency check.

Just tweaking the fsck action bsed on *if* it's mounted (or,
maybe, if the node is in a cluster?) might be a more generic solution
that is widely applicable to all ocfs2 test environments.

Thanks,
-Eric

[1] I know next to nothing about ocfs2, but presumably one can detect
if the device in question is configured into, or mounted in, a cluster?

> Thanks,
> //richard
> 

Re: [PATCH] Do not check ocfs2

[Eric Sandeen]

On 3/3/13 4:19 PM, Richard Weinberger wrote:
> Am Sun, 03 Mar 2013 16:04:48 -0600
> schrieb Eric Sandeen <sandeen@sandeen.net>:
>  > > 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?
> 
> The cluster is already configured. But a single node can mount/unmount
> the fs as it wants.

Ok, so:
a) your cluster is already configured, and 
b) other nodes can mount cluster filesystems

Sure, but - how *did* other nodes mount your xfstest filesystems?
Or did you configure xfstests to use something already configured
to be mounted on multiple nodes?

Perhaps another related question - did the fs *need* to be mounted
on other nodes to expose the problems you found?

I'm just trying to understand if this is a common case, or unique to
how you have configured things.

> I know, xfstests is not a perfect test case for ocfs2 but it allowed me
> to trigger issues...
> These issues can also be triggered without xfstests. But in my case I
> found them using xfstests.

I understand, I'm not suggesting that you not run xfstests; I'm sure
it is useful.  It's supposed to be.  :)  We just need to keep it
useful & not disable the consistency checks unless it's necessary.

>> 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?
> 
> It refuses to check the fs and exists with an error code != 0.

Ok, then that confuses me a little, because earlier you said:

> To ensure that fsck.ocfs2 will not corrupt the filesystem 

but just now you said it won't run at all?  Anyway...

> From the manpage:
>        -F     By default fsck.ocfs2 will check with the cluster
> services to ensure that the volume is not in-use (mounted) on any node
> in the cluster before proceeding.  -F skips this check and should only
> be used when it can be guaranteed that the volume is not mounted on any
> node in the cluster. WARNING: If the cluster check is disabled and the
> volume  is mounted on one or more nodes, file system corruption is very
> likely. If unsure, do not use this option.

Ok, but xfstests wasn't *using* -F was it?

Anyway, what if you did something more along the lines of [pseudocode]

ocfs2)
	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
		;
	else
		fsck.ocfs2 $TEST-DEV
	fi
	;;

so that *if* it's mounted on some other node, the fsck won't run.
That has downsides as Dave mentioned, but for the case where the
xfstests node is the only one with it in use, it'll still do the
beneficial consistency check.

Just tweaking the fsck action bsed on *if* it's mounted (or,
maybe, if the node is in a cluster?) might be a more generic solution
that is widely applicable to all ocfs2 test environments.

Thanks,
-Eric

[1] I know next to nothing about ocfs2, but presumably one can detect
if the device in question is configured into, or mounted in, a cluster?

> Thanks,
> //richard
> 

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

Re: [PATCH] Do not check ocfs2

[Richard Weinberger]

Am Sun, 03 Mar 2013 16:40:26 -0600
schrieb Eric Sandeen <sandeen@sandeen.net>:
> On 3/3/13 4:19 PM, Richard Weinberger wrote:
> > Am Sun, 03 Mar 2013 16:04:48 -0600
> > schrieb Eric Sandeen <sandeen@sandeen.net>:
> >  > > 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?
> > 
> > The cluster is already configured. But a single node can
> > mount/unmount the fs as it wants.
> 
> Ok, so:
> a) your cluster is already configured, and 
> b) other nodes can mount cluster filesystems

Correct.
 
> Sure, but - how *did* other nodes mount your xfstest filesystems?
> Or did you configure xfstests to use something already configured
> to be mounted on multiple nodes?
> 
> Perhaps another related question - did the fs *need* to be mounted
> on other nodes to expose the problems you found?

Yes, seems so.

> I'm just trying to understand if this is a common case, or unique to
> how you have configured things.
> 
> > I know, xfstests is not a perfect test case for ocfs2 but it
> > allowed me to trigger issues...
> > These issues can also be triggered without xfstests. But in my case
> > I found them using xfstests.
> 
> I understand, I'm not suggesting that you not run xfstests; I'm sure
> it is useful.  It's supposed to be.  :)  We just need to keep it
> useful & not disable the consistency checks unless it's necessary.

Fair point.

> >> 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?
> > 
> > It refuses to check the fs and exists with an error code != 0.
> 
> Ok, then that confuses me a little, because earlier you said:
> 
> > To ensure that fsck.ocfs2 will not corrupt the filesystem 
> 
> but just now you said it won't run at all?  Anyway...

In the first test run I faced a filesystem corruption and blamed
fsck.ocfs2. After writing the mail I realized that fsck.ocfs2 aborted
and the corruption came from another issue.
Sorry for being imprecise.

> > From the manpage:
> >        -F     By default fsck.ocfs2 will check with the cluster
> > services to ensure that the volume is not in-use (mounted) on any
> > node in the cluster before proceeding.  -F skips this check and
> > should only be used when it can be guaranteed that the volume is
> > not mounted on any node in the cluster. WARNING: If the cluster
> > check is disabled and the volume  is mounted on one or more nodes,
> > file system corruption is very likely. If unsure, do not use this
> > option.
> 
> Ok, but xfstests wasn't *using* -F was it?

Correct.

> Anyway, what if you did something more along the lines of [pseudocode]
> 
> ocfs2)
> 	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
> 		;
> 	else
> 		fsck.ocfs2 $TEST-DEV
> 	fi
> 	;;
> 
> so that *if* it's mounted on some other node, the fsck won't run.
> That has downsides as Dave mentioned, but for the case where the
> xfstests node is the only one with it in use, it'll still do the
> beneficial consistency check.
> 
> Just tweaking the fsck action bsed on *if* it's mounted (or,
> maybe, if the node is in a cluster?) might be a more generic solution
> that is widely applicable to all ocfs2 test environments.

Good point. mounted.ocfs2 really makes sense. I'll implement this on my
test suite and submit a new patch.

> Thanks,
> -Eric
> 
> [1] I know next to nothing about ocfs2, but presumably one can detect
> if the device in question is configured into, or mounted in, a
> cluster?

I'll find out!

Thanks,
//richard

Re: [PATCH] Do not check ocfs2

[Richard Weinberger]

Am Sun, 03 Mar 2013 16:40:26 -0600
schrieb Eric Sandeen <sandeen@sandeen.net>:
> On 3/3/13 4:19 PM, Richard Weinberger wrote:
> > Am Sun, 03 Mar 2013 16:04:48 -0600
> > schrieb Eric Sandeen <sandeen@sandeen.net>:
> >  > > 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?
> > 
> > The cluster is already configured. But a single node can
> > mount/unmount the fs as it wants.
> 
> Ok, so:
> a) your cluster is already configured, and 
> b) other nodes can mount cluster filesystems

Correct.
 
> Sure, but - how *did* other nodes mount your xfstest filesystems?
> Or did you configure xfstests to use something already configured
> to be mounted on multiple nodes?
> 
> Perhaps another related question - did the fs *need* to be mounted
> on other nodes to expose the problems you found?

Yes, seems so.

> I'm just trying to understand if this is a common case, or unique to
> how you have configured things.
> 
> > I know, xfstests is not a perfect test case for ocfs2 but it
> > allowed me to trigger issues...
> > These issues can also be triggered without xfstests. But in my case
> > I found them using xfstests.
> 
> I understand, I'm not suggesting that you not run xfstests; I'm sure
> it is useful.  It's supposed to be.  :)  We just need to keep it
> useful & not disable the consistency checks unless it's necessary.

Fair point.

> >> 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?
> > 
> > It refuses to check the fs and exists with an error code != 0.
> 
> Ok, then that confuses me a little, because earlier you said:
> 
> > To ensure that fsck.ocfs2 will not corrupt the filesystem 
> 
> but just now you said it won't run at all?  Anyway...

In the first test run I faced a filesystem corruption and blamed
fsck.ocfs2. After writing the mail I realized that fsck.ocfs2 aborted
and the corruption came from another issue.
Sorry for being imprecise.

> > From the manpage:
> >        -F     By default fsck.ocfs2 will check with the cluster
> > services to ensure that the volume is not in-use (mounted) on any
> > node in the cluster before proceeding.  -F skips this check and
> > should only be used when it can be guaranteed that the volume is
> > not mounted on any node in the cluster. WARNING: If the cluster
> > check is disabled and the volume  is mounted on one or more nodes,
> > file system corruption is very likely. If unsure, do not use this
> > option.
> 
> Ok, but xfstests wasn't *using* -F was it?

Correct.

> Anyway, what if you did something more along the lines of [pseudocode]
> 
> ocfs2)
> 	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
> 		;
> 	else
> 		fsck.ocfs2 $TEST-DEV
> 	fi
> 	;;
> 
> so that *if* it's mounted on some other node, the fsck won't run.
> That has downsides as Dave mentioned, but for the case where the
> xfstests node is the only one with it in use, it'll still do the
> beneficial consistency check.
> 
> Just tweaking the fsck action bsed on *if* it's mounted (or,
> maybe, if the node is in a cluster?) might be a more generic solution
> that is widely applicable to all ocfs2 test environments.

Good point. mounted.ocfs2 really makes sense. I'll implement this on my
test suite and submit a new patch.

> Thanks,
> -Eric
> 
> [1] I know next to nothing about ocfs2, but presumably one can detect
> if the device in question is configured into, or mounted in, a
> cluster?

I'll find out!

Thanks,
//richard

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

Re: [PATCH] Do not check ocfs2

[Eric Sandeen]

On 3/3/13 4:53 PM, Richard Weinberger wrote:

>> Anyway, what if you did something more along the lines of [pseudocode]
>>
>> ocfs2)
>> 	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
>> 		;
>> 	else
>> 		fsck.ocfs2 $TEST-DEV
>> 	fi
>> 	;;
>>
>> so that *if* it's mounted on some other node, the fsck won't run.
>> That has downsides as Dave mentioned, but for the case where the
>> xfstests node is the only one with it in use, it'll still do the
>> beneficial consistency check.
>>
>> Just tweaking the fsck action bsed on *if* it's mounted (or,
>> maybe, if the node is in a cluster?) might be a more generic solution
>> that is widely applicable to all ocfs2 test environments.
> 
> Good point. mounted.ocfs2 really makes sense. I'll implement this on my
> test suite and submit a new patch.

Sounds good to me.

It'd be most preferable to do a cluster-wide unmount and fsck,
but if that's unfeasible, then skipping the fsck (with a warning) is
still preferable to simply disabling it outright for everyone.

Thanks,
-Eric

Re: [PATCH] Do not check ocfs2

[Eric Sandeen]

On 3/3/13 4:53 PM, Richard Weinberger wrote:

>> Anyway, what if you did something more along the lines of [pseudocode]
>>
>> ocfs2)
>> 	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
>> 		;
>> 	else
>> 		fsck.ocfs2 $TEST-DEV
>> 	fi
>> 	;;
>>
>> so that *if* it's mounted on some other node, the fsck won't run.
>> That has downsides as Dave mentioned, but for the case where the
>> xfstests node is the only one with it in use, it'll still do the
>> beneficial consistency check.
>>
>> Just tweaking the fsck action bsed on *if* it's mounted (or,
>> maybe, if the node is in a cluster?) might be a more generic solution
>> that is widely applicable to all ocfs2 test environments.
> 
> Good point. mounted.ocfs2 really makes sense. I'll implement this on my
> test suite and submit a new patch.

Sounds good to me.

It'd be most preferable to do a cluster-wide unmount and fsck,
but if that's unfeasible, then skipping the fsck (with a warning) is
still preferable to simply disabling it outright for everyone.

Thanks,
-Eric


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

Re: [PATCH] Do not check ocfs2

[Dave Chinner]

On Sun, Mar 03, 2013 at 04:57:55PM -0600, Eric Sandeen wrote:
> On 3/3/13 4:53 PM, Richard Weinberger wrote:
> 
> >> Anyway, what if you did something more along the lines of [pseudocode]
> >>
> >> ocfs2)
> >> 	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
> >> 		;
> >> 	else
> >> 		fsck.ocfs2 $TEST-DEV
> >> 	fi
> >> 	;;
> >>
> >> so that *if* it's mounted on some other node, the fsck won't run.
> >> That has downsides as Dave mentioned, but for the case where the
> >> xfstests node is the only one with it in use, it'll still do the
> >> beneficial consistency check.
> >>
> >> Just tweaking the fsck action bsed on *if* it's mounted (or,
> >> maybe, if the node is in a cluster?) might be a more generic solution
> >> that is widely applicable to all ocfs2 test environments.
> > 
> > Good point. mounted.ocfs2 really makes sense. I'll implement this on my
> > test suite and submit a new patch.
> 
> Sounds good to me.
> 
> It'd be most preferable to do a cluster-wide unmount and fsck,

Which makes no sense to me, because ./check will then do a cluster
wide unmount as it runs the test harness initialisation. Hence all
the subsequent tests will run with the filesystem only mounted on
the local node....

Really, xfstests is not designed for testing cluster filesystems in
clustered environments. If we really want to support clustered
filesystems and cluster wide operations, then we need to think
about how to architect multi-host support into xfstests sanely.
Clustered filesystems are not the only people that could make use of
such functionality (NFS and CIFS come to mind).... ;)

Cheers,

Dave/
-- 
Dave Chinner
david@fromorbit.com

Re: [PATCH] Do not check ocfs2

[Dave Chinner]

On Sun, Mar 03, 2013 at 04:57:55PM -0600, Eric Sandeen wrote:
> On 3/3/13 4:53 PM, Richard Weinberger wrote:
> 
> >> Anyway, what if you did something more along the lines of [pseudocode]
> >>
> >> ocfs2)
> >> 	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
> >> 		;
> >> 	else
> >> 		fsck.ocfs2 $TEST-DEV
> >> 	fi
> >> 	;;
> >>
> >> so that *if* it's mounted on some other node, the fsck won't run.
> >> That has downsides as Dave mentioned, but for the case where the
> >> xfstests node is the only one with it in use, it'll still do the
> >> beneficial consistency check.
> >>
> >> Just tweaking the fsck action bsed on *if* it's mounted (or,
> >> maybe, if the node is in a cluster?) might be a more generic solution
> >> that is widely applicable to all ocfs2 test environments.
> > 
> > Good point. mounted.ocfs2 really makes sense. I'll implement this on my
> > test suite and submit a new patch.
> 
> Sounds good to me.
> 
> It'd be most preferable to do a cluster-wide unmount and fsck,

Which makes no sense to me, because ./check will then do a cluster
wide unmount as it runs the test harness initialisation. Hence all
the subsequent tests will run with the filesystem only mounted on
the local node....

Really, xfstests is not designed for testing cluster filesystems in
clustered environments. If we really want to support clustered
filesystems and cluster wide operations, then we need to think
about how to architect multi-host support into xfstests sanely.
Clustered filesystems are not the only people that could make use of
such functionality (NFS and CIFS come to mind).... ;)

Cheers,

Dave/
-- 
Dave Chinner
david@fromorbit.com

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

Re: [PATCH] Do not check ocfs2

[Joel Becker]

On Mon, Mar 04, 2013 at 11:42:29AM +1100, Dave Chinner wrote:
> On Sun, Mar 03, 2013 at 04:57:55PM -0600, Eric Sandeen wrote:
> > On 3/3/13 4:53 PM, Richard Weinberger wrote:
> > 
> > >> Anyway, what if you did something more along the lines of [pseudocode]
> > >>
> > >> ocfs2)
> > >> 	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
> > >> 		;
> > >> 	else
> > >> 		fsck.ocfs2 $TEST-DEV
> > >> 	fi
> > >> 	;;
> > >>
> > >> so that *if* it's mounted on some other node, the fsck won't run.
> > >> That has downsides as Dave mentioned, but for the case where the
> > >> xfstests node is the only one with it in use, it'll still do the
> > >> beneficial consistency check.
> > >>
> > >> Just tweaking the fsck action bsed on *if* it's mounted (or,
> > >> maybe, if the node is in a cluster?) might be a more generic solution
> > >> that is widely applicable to all ocfs2 test environments.
> > > 
> > > Good point. mounted.ocfs2 really makes sense. I'll implement this on my
> > > test suite and submit a new patch.
> > 
> > Sounds good to me.
> > 
> > It'd be most preferable to do a cluster-wide unmount and fsck,
> 
> Which makes no sense to me, because ./check will then do a cluster
> wide unmount as it runs the test harness initialisation. Hence all
> the subsequent tests will run with the filesystem only mounted on
> the local node....
> 
> Really, xfstests is not designed for testing cluster filesystems in
> clustered environments. If we really want to support clustered
> filesystems and cluster wide operations, then we need to think
> about how to architect multi-host support into xfstests sanely.
> Clustered filesystems are not the only people that could make use of
> such functionality (NFS and CIFS come to mind).... ;)

I'm much happier with the "check for other cluster mounts" approach
rather than avoiding fsck entirely.  We like xfstests in the local or
single-node cases to behave exactly as one would expect.

We do run xfstests on multiple nodes in a cluster, but by hand and with
our own cleanup.  Obviously support for automating that would be awesome
:-)

Joel

> 
> Cheers,
> 
> Dave/
> -- 
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

"Born under a bad sign.
 I been down since I began to crawl.
 If it wasn't for bad luck,
 I wouldn't have no luck at all."

			http://www.jlbec.org/
			jlbec@evilplan.org

Re: [PATCH] Do not check ocfs2

[Joel Becker]

On Mon, Mar 04, 2013 at 11:42:29AM +1100, Dave Chinner wrote:
> On Sun, Mar 03, 2013 at 04:57:55PM -0600, Eric Sandeen wrote:
> > On 3/3/13 4:53 PM, Richard Weinberger wrote:
> > 
> > >> Anyway, what if you did something more along the lines of [pseudocode]
> > >>
> > >> ocfs2)
> > >> 	if mounted.ocfs2 -f $TEST-DEV | frob_as_necessary[1]
> > >> 		;
> > >> 	else
> > >> 		fsck.ocfs2 $TEST-DEV
> > >> 	fi
> > >> 	;;
> > >>
> > >> so that *if* it's mounted on some other node, the fsck won't run.
> > >> That has downsides as Dave mentioned, but for the case where the
> > >> xfstests node is the only one with it in use, it'll still do the
> > >> beneficial consistency check.
> > >>
> > >> Just tweaking the fsck action bsed on *if* it's mounted (or,
> > >> maybe, if the node is in a cluster?) might be a more generic solution
> > >> that is widely applicable to all ocfs2 test environments.
> > > 
> > > Good point. mounted.ocfs2 really makes sense. I'll implement this on my
> > > test suite and submit a new patch.
> > 
> > Sounds good to me.
> > 
> > It'd be most preferable to do a cluster-wide unmount and fsck,
> 
> Which makes no sense to me, because ./check will then do a cluster
> wide unmount as it runs the test harness initialisation. Hence all
> the subsequent tests will run with the filesystem only mounted on
> the local node....
> 
> Really, xfstests is not designed for testing cluster filesystems in
> clustered environments. If we really want to support clustered
> filesystems and cluster wide operations, then we need to think
> about how to architect multi-host support into xfstests sanely.
> Clustered filesystems are not the only people that could make use of
> such functionality (NFS and CIFS come to mind).... ;)

I'm much happier with the "check for other cluster mounts" approach
rather than avoiding fsck entirely.  We like xfstests in the local or
single-node cases to behave exactly as one would expect.

We do run xfstests on multiple nodes in a cluster, but by hand and with
our own cleanup.  Obviously support for automating that would be awesome
:-)

Joel

> 
> Cheers,
> 
> Dave/
> -- 
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

"Born under a bad sign.
 I been down since I began to crawl.
 If it wasn't for bad luck,
 I wouldn't have no luck at all."

			http://www.jlbec.org/
			jlbec@evilplan.org

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

Re: [PATCH] Do not check ocfs2

[Richard Weinberger]

Am Mon, 4 Mar 2013 13:05:23 -0800
schrieb Joel Becker <jlbec@evilplan.org>:
> > Really, xfstests is not designed for testing cluster filesystems in
> > clustered environments. If we really want to support clustered
> > filesystems and cluster wide operations, then we need to think
> > about how to architect multi-host support into xfstests sanely.
> > Clustered filesystems are not the only people that could make use of
> > such functionality (NFS and CIFS come to mind).... ;)
> 
> I'm much happier with the "check for other cluster mounts" approach
> rather than avoiding fsck entirely.  We like xfstests in the local or
> single-node cases to behave exactly as one would expect.
> 
> We do run xfstests on multiple nodes in a cluster, but by hand and
> with our own cleanup.  Obviously support for automating that would be
> awesome :-)

Can you share your cleanup code?

Thanks,
//richard

Re: [PATCH] Do not check ocfs2

[Richard Weinberger]

Am Mon, 4 Mar 2013 13:05:23 -0800
schrieb Joel Becker <jlbec@evilplan.org>:
> > Really, xfstests is not designed for testing cluster filesystems in
> > clustered environments. If we really want to support clustered
> > filesystems and cluster wide operations, then we need to think
> > about how to architect multi-host support into xfstests sanely.
> > Clustered filesystems are not the only people that could make use of
> > such functionality (NFS and CIFS come to mind).... ;)
> 
> I'm much happier with the "check for other cluster mounts" approach
> rather than avoiding fsck entirely.  We like xfstests in the local or
> single-node cases to behave exactly as one would expect.
> 
> We do run xfstests on multiple nodes in a cluster, but by hand and
> with our own cleanup.  Obviously support for automating that would be
> awesome :-)

Can you share your cleanup code?

Thanks,
//richard

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

Re: [PATCH] Do not check ocfs2

[Joel Becker]

On Mon, Mar 04, 2013 at 11:09:22PM +0100, Richard Weinberger wrote:
> Am Mon, 4 Mar 2013 13:05:23 -0800
> schrieb Joel Becker <jlbec@evilplan.org>:
> > > Really, xfstests is not designed for testing cluster filesystems in
> > > clustered environments. If we really want to support clustered
> > > filesystems and cluster wide operations, then we need to think
> > > about how to architect multi-host support into xfstests sanely.
> > > Clustered filesystems are not the only people that could make use of
> > > such functionality (NFS and CIFS come to mind).... ;)
> > 
> > I'm much happier with the "check for other cluster mounts" approach
> > rather than avoiding fsck entirely.  We like xfstests in the local or
> > single-node cases to behave exactly as one would expect.
> > 
> > We do run xfstests on multiple nodes in a cluster, but by hand and
> > with our own cleanup.  Obviously support for automating that would be
> > awesome :-)
> 
> Can you share your cleanup code?

It's not code, unless you count DNA and neuron connections...

Joel

> 
> Thanks,
> //richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Life's Little Instruction Book #139

	"Never deprive someone of hope; it might be all they have."

			http://www.jlbec.org/
			jlbec@evilplan.org

Re: [PATCH] Do not check ocfs2

[Joel Becker]

On Mon, Mar 04, 2013 at 11:09:22PM +0100, Richard Weinberger wrote:
> Am Mon, 4 Mar 2013 13:05:23 -0800
> schrieb Joel Becker <jlbec@evilplan.org>:
> > > Really, xfstests is not designed for testing cluster filesystems in
> > > clustered environments. If we really want to support clustered
> > > filesystems and cluster wide operations, then we need to think
> > > about how to architect multi-host support into xfstests sanely.
> > > Clustered filesystems are not the only people that could make use of
> > > such functionality (NFS and CIFS come to mind).... ;)
> > 
> > I'm much happier with the "check for other cluster mounts" approach
> > rather than avoiding fsck entirely.  We like xfstests in the local or
> > single-node cases to behave exactly as one would expect.
> > 
> > We do run xfstests on multiple nodes in a cluster, but by hand and
> > with our own cleanup.  Obviously support for automating that would be
> > awesome :-)
> 
> Can you share your cleanup code?

It's not code, unless you count DNA and neuron connections...

Joel

> 
> Thanks,
> //richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Life's Little Instruction Book #139

	"Never deprive someone of hope; it might be all they have."

			http://www.jlbec.org/
			jlbec@evilplan.org

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