public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: xfs-dev <xfs-dev@sgi.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Review: fix b0rked test 030 behaviour.
Date: Fri, 11 May 2007 11:11:45 +1000	[thread overview]
Message-ID: <20070511011145.GN86004887@sgi.com> (raw)

Test 030 is not testing things as it should.

Specifically, corrupting the AGFL with "-1" is a no-op on
a freshly repaired filesystem, because xfs_repair rebuilds
the AGF btrees and AGFL from scratch and does not populate
the AGFL.

The current test does:

	repair
	mount
	create file
	remove file
	umount

And it does the filesystem twiddling to check that the filesystem
is ußable after repair. The problem is that this doesn't dirty the
filesystem - the create is followed by a remove, so nothing is
actually allocated and so the AGFL lists do not get modified.

hence after a repair/check/corruption cycle, writing "-1" to
the AGFL is a no-op because it is already full of "-1" fields
(NULL blocks).

With filestreams, the create/remove pair *does* modify the filesystem
and so when we write "-1" to the AGFL, we get different output
because the filesystem detects new corruptions and the test "fails".

So, to make behaviour consistent, dirty the filesystem before
corrupting it on each cycle. Hence it doesn't matter if we are
using filestreams or not, we'll really test out corrupting the
AGFL with NULL blocks (-1) now.

Comments?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


---
 xfstests/030.out.irix  |    4 ++++
 xfstests/030.out.linux |    4 ++++
 xfstests/common.repair |   10 ++++++++++
 3 files changed, 18 insertions(+)

Index: xfs-cmds/xfstests/030.out.irix
===================================================================
--- xfs-cmds.orig/xfstests/030.out.irix	2007-05-03 17:10:29.554803451 +1000
+++ xfs-cmds/xfstests/030.out.irix	2007-05-03 17:10:54.227585189 +1000
@@ -262,6 +262,10 @@ Wrote X.XXKb (value 0xffffffff)
 Phase 1 - find and verify superblock...
 Phase 2 - zero log...
         - scan filesystem freespace and inode maps...
+bad agbno AGBNO in agfl, agno 0
+bad agbno AGBNO in agfl, agno 0
+bad agbno AGBNO in agfl, agno 0
+bad agbno AGBNO in agfl, agno 0
         - found root inode chunk
 Phase 3 - for each AG...
         - scan and clear agi unlinked lists...
Index: xfs-cmds/xfstests/030.out.linux
===================================================================
--- xfs-cmds.orig/xfstests/030.out.linux	2007-05-03 17:10:29.554803451 +1000
+++ xfs-cmds/xfstests/030.out.linux	2007-05-03 17:10:54.231584667 +1000
@@ -270,6 +270,10 @@ Phase 1 - find and verify superblock...
 Phase 2 - using <TYPEOF> log
         - zero log...
         - scan filesystem freespace and inode maps...
+bad agbno AGBNO in agfl, agno 0
+bad agbno AGBNO in agfl, agno 0
+bad agbno AGBNO in agfl, agno 0
+bad agbno AGBNO in agfl, agno 0
         - found root inode chunk
 Phase 3 - for each AG...
         - scan and clear agi unlinked lists...
Index: xfs-cmds/xfstests/common.repair
===================================================================
--- xfs-cmds.orig/xfstests/common.repair	2007-05-03 17:10:29.554803451 +1000
+++ xfs-cmds/xfstests/common.repair	2007-05-03 17:10:54.231584667 +1000
@@ -72,8 +72,18 @@ _check_repair()
 {
 	value=$1
 	structure="$2"
+
+	#ensure the filesystem has been dirtied since last repair
+	_scratch_mount
+	POSIXLY_CORRECT=yes \
+	dd if=/bin/sh of=$SCRATCH_MNT/sh 2>&1 |_filter_dd
+	sync
+	rm -f $SCRATCH_MNT/sh
+	umount $SCRATCH_MNT
+
 	_zero_position $value "$structure"
 	_scratch_xfs_repair 2>&1 | _filter_repair
+
 	# some basic sanity checks...
 	_check_scratch_fs
 	_scratch_mount                                      #mount

             reply	other threads:[~2007-05-11  1:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-11  1:11 David Chinner [this message]
2007-05-17  7:36 ` Review: fix b0rked test 030 behaviour David Disseldorp

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=20070511011145.GN86004887@sgi.com \
    --to=dgc@sgi.com \
    --cc=xfs-dev@sgi.com \
    --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