From: "Theodore Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Eryu Guan <eguan@redhat.com>, fstests@vger.kernel.org
Subject: Re: [RFC PATCH] check: try to fix the test device if it gets corrupted
Date: Sun, 26 Mar 2017 21:48:02 -0400 [thread overview]
Message-ID: <20170327014802.wc5as2tdgecy3rzu@thunk.org> (raw)
In-Reply-To: <20170303230129.apzqe77r4d5jtf63@thunk.org>
On Fri, Mar 03, 2017 at 06:01:29PM -0500, Theodore Ts'o wrote:
> On Fri, Mar 03, 2017 at 09:21:57AM -0800, Darrick J. Wong wrote:
> >
> > <shrug> The test device isn't supposed to get corrupted, since it (at
> > least in theory) should be an old filesystem. That said, I suppose
> > there's little point in banging around with a corrupt test fs. Maybe we
> > could go further and stop running if there's unfixable corruption?
>
> Yes, that was the other alternative I considered. In my case, though,
> since I'm trying to get a sense of how many failures I have to deal
> with, I really wanted a "make -k" behavior that would continue after
> the first failure. After all, all I was going to do was manually run
> fsck, and then continue the run --- so we might as well have the check
> script do it automatically and then allow things to continue.
>
> We could make it be configurable, via a command-line option. The -k
> option isn't taken so we could have check -k that works like make -k
> if you think that's better. OTOH, perhaps making -k the default
> behaviour is actually the better way to go, and in that case, maybe
> it's not worth having the command-line flag?
Eryu, do you have any preferences or comments about how you'd like me
to modify this patch for upstreaming? (Attached is my current version
of the patch).
Thanks!!
- Ted
commit 727c737d1f0a40288fc897c0263fbf8e7a5db8b3
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Mar 1 19:54:08 2017 -0500
check: try to fix the test device if it gets corrupted
If the test device gets corrupted all subsequent tests will fail. To
prevent this from causing all subsequent tests to be useless, try
repair the file system on TEST_DEV if possible. We don't need to do
this with the scratch device since that file system gets recreated
each time anyway.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
diff --git a/check b/check
index 2fcf385f..d253f744 100755
--- a/check
+++ b/check
@@ -472,7 +472,11 @@ _summary()
_check_filesystems()
{
if [ -f ${RESULT_DIR}/require_test ]; then
- _check_test_fs || err=true
+ if ! _check_test_fs ; then
+ err=true
+ echo "Trying to repair broken TEST_DEV file system"
+ _repair_test_fs
+ fi
rm -f ${RESULT_DIR}/require_test*
fi
if [ -f ${RESULT_DIR}/require_scratch ]; then
diff --git a/common/rc b/common/rc
index 052f67aa..ce491f3f 100644
--- a/common/rc
+++ b/common/rc
@@ -1172,6 +1172,28 @@ _repair_scratch_fs()
esac
}
+_repair_test_fs()
+{
+ case $FSTYP in
+ ext2|ext3|ext4)
+ fsck -t $FSTYP -fy $TEST_DEV >$tmp.repair 2>&1
+ if test $? -ge 4 ; then
+ echo "_repair_test_fs: couldn't repair filesystem on $device (see $seqres.full)"
+
+ echo "_repair_test_fs: couldn't repair filesystem on $device" >>$seqres.full
+ echo "*** fsck.$FSTYP output ***" >>$seqres.full
+ cat $tmp.repair >>$seqres.full
+ echo "*** end fsck.$FSTYP output" >>$seqres.full
+ return 1
+ fi
+ return 0
+ ;;
+ *)
+ return 1
+ ;;
+ esac
+}
+
_get_pids_by_name()
{
if [ $# -ne 1 ]
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=-yMrTV4jriXR7ieyzzjV-QgHBD0UDw8ixoR77aMeAHE&m=TzkdhjUlBq8jw7ezkl6BuvazC1ulmLiwN0_zxLN0WsE&s=BrM0YkzpJep1zV6T-XPTWCIjCTjMYv_CK_yzXPCXfKY&e=
next prev parent reply other threads:[~2017-03-27 1:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 23:20 [RFC PATCH] check: try to fix the test device if it gets corrupted Theodore Ts'o
2017-03-03 9:03 ` Eryu Guan
2017-03-03 17:21 ` Darrick J. Wong
2017-03-03 23:01 ` Theodore Ts'o
2017-03-27 1:48 ` Theodore Ts'o [this message]
2017-03-27 8:51 ` Eryu Guan
2017-07-16 1:30 ` Theodore Ts'o
2017-07-17 23:45 ` Darrick J. Wong
2017-07-18 5:05 ` Eryu Guan
2017-07-18 17:30 ` Theodore Ts'o
2017-07-19 9:40 ` Eryu Guan
2017-07-19 14:53 ` Theodore Ts'o
2017-07-19 15:02 ` Eryu Guan
2017-07-19 16:13 ` Darrick J. Wong
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=20170327014802.wc5as2tdgecy3rzu@thunk.org \
--to=tytso@mit.edu \
--cc=darrick.wong@oracle.com \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
/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