* [PATCH] Do not check ocfs2 @ 2013-03-03 0:05 Richard Weinberger 2013-03-03 1:19 ` Dave Chinner 0 siblings, 1 reply; 12+ messages in thread From: Richard Weinberger @ 2013-03-03 0:05 UTC (permalink / raw) To: xfs; +Cc: linux-fsdevel, 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 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 0 siblings, 1 reply; 12+ messages in thread From: Dave Chinner @ 2013-03-03 1:19 UTC (permalink / raw) To: Richard Weinberger; +Cc: xfs, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-03 1:19 ` Dave Chinner @ 2013-03-03 9:02 ` Richard Weinberger 2013-03-03 22:04 ` Eric Sandeen 0 siblings, 1 reply; 12+ messages in thread From: Richard Weinberger @ 2013-03-03 9:02 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-03 9:02 ` Richard Weinberger @ 2013-03-03 22:04 ` Eric Sandeen 2013-03-03 22:19 ` Richard Weinberger 0 siblings, 1 reply; 12+ messages in thread From: Eric Sandeen @ 2013-03-03 22:04 UTC (permalink / raw) To: Richard Weinberger; +Cc: linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-03 22:04 ` Eric Sandeen @ 2013-03-03 22:19 ` Richard Weinberger 2013-03-03 22:40 ` Eric Sandeen 0 siblings, 1 reply; 12+ messages in thread From: Richard Weinberger @ 2013-03-03 22:19 UTC (permalink / raw) To: Eric Sandeen; +Cc: Dave Chinner, linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-03 22:19 ` Richard Weinberger @ 2013-03-03 22:40 ` Eric Sandeen 2013-03-03 22:53 ` Richard Weinberger 0 siblings, 1 reply; 12+ messages in thread From: Eric Sandeen @ 2013-03-03 22:40 UTC (permalink / raw) To: Richard Weinberger; +Cc: Dave Chinner, linux-fsdevel, xfs 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-03 22:40 ` Eric Sandeen @ 2013-03-03 22:53 ` Richard Weinberger 2013-03-03 22:57 ` Eric Sandeen 0 siblings, 1 reply; 12+ messages in thread From: Richard Weinberger @ 2013-03-03 22:53 UTC (permalink / raw) To: Eric Sandeen; +Cc: Dave Chinner, linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-03 22:53 ` Richard Weinberger @ 2013-03-03 22:57 ` Eric Sandeen 2013-03-04 0:42 ` Dave Chinner 0 siblings, 1 reply; 12+ messages in thread From: Eric Sandeen @ 2013-03-03 22:57 UTC (permalink / raw) To: Richard Weinberger; +Cc: Dave Chinner, linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-03 22:57 ` Eric Sandeen @ 2013-03-04 0:42 ` Dave Chinner 2013-03-04 21:05 ` Joel Becker 0 siblings, 1 reply; 12+ messages in thread From: Dave Chinner @ 2013-03-04 0:42 UTC (permalink / raw) To: Eric Sandeen; +Cc: Richard Weinberger, linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-04 0:42 ` Dave Chinner @ 2013-03-04 21:05 ` Joel Becker 2013-03-04 22:09 ` Richard Weinberger 0 siblings, 1 reply; 12+ messages in thread From: Joel Becker @ 2013-03-04 21:05 UTC (permalink / raw) To: Dave Chinner; +Cc: Eric Sandeen, Richard Weinberger, linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-04 21:05 ` Joel Becker @ 2013-03-04 22:09 ` Richard Weinberger 2013-03-04 22:57 ` Joel Becker 0 siblings, 1 reply; 12+ messages in thread From: Richard Weinberger @ 2013-03-04 22:09 UTC (permalink / raw) To: Joel Becker; +Cc: Dave Chinner, Eric Sandeen, linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Do not check ocfs2 2013-03-04 22:09 ` Richard Weinberger @ 2013-03-04 22:57 ` Joel Becker 0 siblings, 0 replies; 12+ messages in thread From: Joel Becker @ 2013-03-04 22:57 UTC (permalink / raw) To: Richard Weinberger; +Cc: Dave Chinner, Eric Sandeen, linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-03-04 22:57 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).