From: Eric Sandeen <sandeen@redhat.com>
To: xfs-oss <xfs@oss.sgi.com>
Subject: [PATCH] xfstest 285: userspace vs. fragmented multiblock dir2
Date: Mon, 21 May 2012 17:05:53 -0500 [thread overview]
Message-ID: <4FBABC41.5040001@redhat.com> (raw)
Current xfs_repair is unhappy with fragmented multiblock
v2 directories. This test shows it ... patches to fix
it soon to follow.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
diff --git a/285 b/285
new file mode 100755
index 0000000..11a66f6
--- /dev/null
+++ b/285
@@ -0,0 +1,128 @@
+#! /bin/bash
+# FS QA Test No. 285
+#
+# Test userspace on a fragmented multi-block dir2 filesystem
+#
+#-----------------------------------------------------------------------
+# Copyright (c) Red Hat, Inc. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#-----------------------------------------------------------------------
+#
+# creator
+owner=sandeen@sandeen.net
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+ cd /
+ rm -f $tmp.*
+}
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fs xfs
+_supported_os IRIX Linux
+
+# real QA test starts here
+rm -f $seq.full
+_require_scratch
+_scratch_mkfs_xfs -n size=16k -d size=128m >> $seq.full 2>&1
+_scratch_mount
+
+# First we cause very badly fragmented freespace, then
+# make some multiblock directories in the filesystem, which
+# should come out very fragmented as a result
+
+# Step 1: Cause badly fragmented free space
+mkdir $SCRATCH_MNT/fragdir
+for I in `seq 0 27200`; do
+ (echo data > $SCRATCH_MNT/fragdir/f$I) >> $seq.full 2>&1
+done
+sync
+
+for I in `seq 0 2 27200`; do
+ rm -f $SCRATCH_MNT/fragdir/f$I >> $seq.full 2>&1
+done
+sync
+
+# Soak up any remaining freespace
+xfs_io -f -c "pwrite 0 16m" -c "fsync" $SCRATCH_MNT/space_file.large >> $seq.full 2>&1
+
+# Take a look at freespace for any post-mortem on the test
+_scratch_unmount
+xfs_db -c freesp $SCRATCH_DEV >> $seq.full 2>&1
+_scratch_mount
+
+# Step 2: Make a bunch of (hopefully fragmented) multiblock
+# dir2 directories
+
+# - FMT_LOCAL
+mkdir $SCRATCH_MNT/S_IFDIR.FMT_LOCAL
+touch $SCRATCH_MNT/S_IFDIR.FMT_LOCAL/localdirfile
+
+# - FMT_EXTENTS
+mkdir $SCRATCH_MNT/S_IFDIR.FMT_EXTENTS
+for I in `seq 1 100`; do
+ touch $SCRATCH_MNT/S_IFDIR.FMT_EXTENTS/extent_dir_file_$I
+done
+# With a few missing
+for I in `seq 10 2 20` 100; do
+ rm -f $SCRATCH_MNT/S_IFDIR.FMT_EXTENTS/extent_dir_file_$I
+done
+
+# - FMT_BTREE
+mkdir $SCRATCH_MNT/S_IFDIR.FMT_BTREE
+for I in `seq 1 1000`; do
+ touch $SCRATCH_MNT/S_IFDIR.FMT_BTREE/btree_dir_file_$I
+done
+# With a few missing
+for I in `seq 10 2 20` 1000; do
+ rm -f $SCRATCH_MNT/S_IFDIR.FMT_BTREE/btree_dir_file_$I
+done
+
+# Dave's special hack - grow freespace tree
+mkdir $SCRATCH_MNT/S_IFDIR.FMT_BTREE2
+for I in `seq 1 5000`; do
+ touch $SCRATCH_MNT/S_IFDIR.FMT_BTREE2/btree2_dir_file_$I
+done
+# Remove every other (odds)
+for I in `seq 1 2 5000`; do
+ rm -f $SCRATCH_MNT/S_IFDIR.FMT_BTREE2/btree2_dir_file_$I
+done
+
+_scratch_unmount
+# Can xfs_repair and xfs_check cope with this monster?
+_scratch_xfs_repair >> $seq.full 2>&1 || _fail "xfs_repair failed"
+xfs_check $SCRATCH_DEV >> $seq.full 2>&1 || _fail "xfs_check failed"
+
+# Yes they can! Now...
+# Can xfs_metadump cope with this monster?
+xfs_metadump $SCRATCH_DEV $tmp.metadump || _fail "xfs_metadump failed"
+xfs_mdrestore $tmp.metadump $tmp.img || _fail "xfs_mdrestore failed"
+xfs_repair $tmp.img >> $seq.full 2>&1 || _fail "xfs_repair of metadump failed"
+
+# Yes it can; success, all done
+status=0
+exit
+
diff --git a/group b/group
index 104ed35..17afdcd 100644
--- a/group
+++ b/group
@@ -403,3 +403,4 @@ deprecated
282 dump ioctl auto quick
283 dump ioctl auto quick
284 auto
+285 repair dir auto
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2012-05-21 22:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-21 22:05 Eric Sandeen [this message]
2012-06-05 22:46 ` [PATCH] xfstest 285: userspace vs. fragmented multiblock dir2 Ben Myers
2012-06-05 23:48 ` Dave Chinner
2012-06-06 0:57 ` Eric Sandeen
2012-06-06 2:29 ` [PATCH V2] xfstest 287: " Eric Sandeen
2012-11-20 15:28 ` Mark Tinguely
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=4FBABC41.5040001@redhat.com \
--to=sandeen@redhat.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