* group for tests that are dangerous for verifiers?
@ 2013-06-20 17:54 Mark Tinguely
2013-06-21 18:26 ` Michael L. Semon
2013-06-21 18:45 ` Eric Sandeen
0 siblings, 2 replies; 7+ messages in thread
From: Mark Tinguely @ 2013-06-20 17:54 UTC (permalink / raw)
To: xfs-oss, Dave Chinner
Do we need a xfstest verifier dangerous group?
xfstest 111 purposely damages inodes. In hindsight it make sense
that it asserts when running with verifiers.
mkfs.xfs -f /dev/sda3
meta-data=/dev/sda3 isize=256 agcount=4, agsize=4194496 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=16777984, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=8192, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
db/xfs_db /dev/sda3
xfs_db> sb 0
xfs_db> p
magicnum = 0x58465342
blocksize = 4096
dblocks = 16777984
rblocks = 0
rextents = 0
uuid = fd78c924-79c8-4cc4-af42-c5a8b505ab05
logstart = 16777220
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 1
agblocks = 4194496
agcount = 4
rbmblocks = 0
logblocks = 8192
versionnum = 0xb4a4
sectsize = 512
inodesize = 256
inopblock = 16
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 23
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 64
ifree = 61
fdblocks = 16769772
frextents = 0
uquotino = 0
gquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 1
features2 = 0xa
bad_features2 = 0xa
72715.142266] XFS (sda3): Mounting Filesystem
[72715.811778] XFS (sda3): Corruption detected. Unmount and run xfs_repair
[72715.818396] XFS (sda3): bad inode magic/vsn daddr 64 #8 (magic=5858)
[72715.824748] XFS: Assertion failed: 0, file:
/root/xfs/fs/xfs/xfs_inode.c, line: 417
PID: 271 TASK: ffff88034fb365c0 CPU: 1 COMMAND: "kworker/1:1H"
#0 [ffff88034f407a10] machine_kexec at ffffffff8102a0c0
#1 [ffff88034f407a60] crash_kexec at ffffffff810a4943
#2 [ffff88034f407b30] oops_end at ffffffff8145dc10
#3 [ffff88034f407b60] die at ffffffff81005693
#4 [ffff88034f407b90] do_trap at ffffffff8145d583
#5 [ffff88034f407bf0] do_invalid_op at ffffffff81002de0
#6 [ffff88034f407c90] invalid_op at ffffffff81465ca8
[exception RIP: assfail+29]
RIP: ffffffffa04614dd RSP: ffff88034f407d48 RFLAGS: 00010296
RAX: 0000000000000047 RBX: ffff88034dedc800 RCX: 0000000000000dda
RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffffffff81a2dfc0
RBP: ffff88034f407d48 R8: ffffffff81cd4848 R9: ffffffff81ce7003
R10: 0000000000000068 R11: 000000000002d89c R12: 0000000000000008
R13: ffff88034f57ee40 R14: ffff88034f0ba800 R15: 0000000000000020
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffff88034f407d50] xfs_inode_buf_verify at ffffffffa04aa400 [xfs]
#8 [ffff88034f407db0] xfs_inode_buf_read_verify at ffffffffa04aa4b9 [xfs]
#9 [ffff88034f407dc0] xfs_buf_iodone_work at ffffffffa044fd45 [xfs]
#10 [ffff88034f407df0] process_one_work at ffffffff81059c8f
#11 [ffff88034f407e50] worker_thread at ffffffff8105ad3b
#12 [ffff88034f407ec0] kthread at ffffffff810612fb
#13 [ffff88034f407f50] ret_from_fork at ffffffff81464b6c
PID: 20866 TASK: ffff880351f24180 CPU: 1 COMMAND: "mount"
#0 [ffff88035175f7c8] __schedule at ffffffff8145b6fe
#1 [ffff88035175f850] schedule at ffffffff8145bb34
#2 [ffff88035175f860] schedule_timeout at ffffffff81459bd5
#3 [ffff88035175f910] wait_for_completion at ffffffff8145ac6d
#4 [ffff88035175f970] xfs_buf_iowait at ffffffffa0450a09 [xfs]
#5 [ffff88035175f9b0] _xfs_buf_read at ffffffffa0450bf9 [xfs]
#6 [ffff88035175f9d0] xfs_buf_read_map at ffffffffa0450cf3 [xfs]
#7 [ffff88035175fa20] xfs_trans_read_buf_map at ffffffffa04ca0e9 [xfs]
#8 [ffff88035175fa90] xfs_imap_to_bp at ffffffffa04aa52b [xfs]
#9 [ffff88035175fb10] xfs_iread at ffffffffa04b0e5d [xfs]
#10 [ffff88035175fb80] xfs_iget_cache_miss at ffffffffa04586a0 [xfs]
#11 [ffff88035175fbf0] xfs_iget at ffffffffa0459589 [xfs]
#12 [ffff88035175fc80] xfs_mountfs at ffffffffa04bad49 [xfs]
#13 [ffff88035175fcf0] xfs_fs_fill_super at ffffffffa0464ad7 [xfs]
#14 [ffff88035175fd30] mount_bdev at ffffffff81155f85
#15 [ffff88035175fdb0] xfs_fs_mount at ffffffffa04626d0 [xfs]
#16 [ffff88035175fdc0] mount_fs at ffffffff81156bee
#17 [ffff88035175fe10] vfs_kern_mount at ffffffff8116fe21
#18 [ffff88035175fe60] do_new_mount at ffffffff8117136f
#19 [ffff88035175fec0] do_mount at ffffffff811729b6
#20 [ffff88035175ff20] sys_mount at ffffffff81172a8b
#21 [ffff88035175ff80] system_call_fastpath at ffffffff81464c12
RIP: 00007fbcdfd09daa RSP: 00007fffcb9f6f38 RFLAGS: 00010202
RAX: 00000000000000a5 RBX: ffffffff81464c12 RCX: ffffffffffffffc8
RDX: 00007fbce0a6ce80 RSI: 00007fbce0a6ce60 RDI: 00007fbce0a6ce40
RBP: 00000000c0ed0400 R8: 0000000000000000 R9: 0101010101010101
R10: ffffffffc0ed0400 R11: 0000000000000202 R12: 00007fbce0a6ce60
R13: 00007fbce0a6cde0 R14: 0000000000000400 R15: 0000000000000000
ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: group for tests that are dangerous for verifiers?
2013-06-20 17:54 group for tests that are dangerous for verifiers? Mark Tinguely
@ 2013-06-21 18:26 ` Michael L. Semon
2013-06-21 18:45 ` Eric Sandeen
1 sibling, 0 replies; 7+ messages in thread
From: Michael L. Semon @ 2013-06-21 18:26 UTC (permalink / raw)
To: Mark Tinguely; +Cc: xfs-oss
On 06/20/2013 01:54 PM, Mark Tinguely wrote:
> Do we need a xfstest verifier dangerous group?
>
> xfstest 111 purposely damages inodes. In hindsight it make sense
> that it asserts when running with verifiers.
But is the assert needed?
I have to remove the assert to avoid a recursive-fault oops on 32-bit
x86. A test run is included at the end of this letter, and you might
see if the behavior is OK.
There are two patches here. One is the assert removal, made after all
of Dave's recent changes for 3.11. The second is a quick-and-dirty
patch to fix xfs/111 for the `make install` version of xfstests. The
latter one is not used for the sample output here.
Thanks for considering this case. A review on something other than
32-bit x86 would be quite helpful.
If nothing else, might Dave take a look at the xfs_repair output from
my results here? The one-line difference is "fatal error -- couldn't
iget realtime bitmap inode -- error - 117". On one hand, I was working
with rtdevs recently, and the rtdevs probably weren't zeroed out. OTOH,
I was able to fix it using the latest released xfsprogs from an
alternate partition (kernel 3.9.5).
Thanks, and have a good weekend!
Michael
>From e51ad981dd93966a2a24f62678ab8d6163ac2111 Mon Sep 17 00:00:00 2001
From: "Michael L. Semon" <mlsemon35@gmail.com>
Date: Fri, 21 Jun 2013 12:03:01 -0400
Subject: [PATCH] Remove assert to avoid recursive-fault oops on 32-bit x86
This patch removes an assert exclusively for the purpose of getting
past xfstests xfs/111 without it causing a recursive-fault oops.
The fall-through case for this removal has not been fatal but still
should be reviewed by an expert.
Signed-off-by: Michael L. Semon <mlsemon35@gmail.com>
---
fs/xfs/xfs_inode_buf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/xfs/xfs_inode_buf.c b/fs/xfs/xfs_inode_buf.c
index 99c6acb..426f1a7 100644
--- a/fs/xfs/xfs_inode_buf.c
+++ b/fs/xfs/xfs_inode_buf.c
@@ -92,7 +92,6 @@ xfs_inode_buf_verify(
"bad inode magic/vsn daddr %lld #%d (magic=%x)",
(unsigned long long)bp->b_bn, i,
be16_to_cpu(dip->di_magic));
- ASSERT(0);
#endif
}
}
--
1.8.3
>From e44e5e46ae9f4f29a69485088b873a2d5d55726b Mon Sep 17 00:00:00 2001
From: "Michael L. Semon" <mlsemon35@gmail.com>
Date: Fri, 21 Jun 2013 12:44:57 -0400
Subject: [PATCH] xfstests: give xfs/111 a file to copy and trash later
xfs/111 copies src/itrash.c to $SCRATCH_DEV so it can be trashed
later. However, src/itrash.c is not installed by `make install`,
so use instead a file that is known to be installed.
Signed-off-by: Michael L. Semon <mlsemon35@gmail.com>
---
tests/xfs/111 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/xfs/111 b/tests/xfs/111
index bedead8..c7ca489 100755
--- a/tests/xfs/111
+++ b/tests/xfs/111
@@ -53,7 +53,7 @@ echo Create some files
I=0
while [ $I -lt 1000 ]
do
- cp src/itrash.c $SCRATCH_MNT/${I}
+ cp src/itrash $SCRATCH_MNT/${I}
let I=$I+1
done
umount $SCRATCH_DEV
--
1.8.3
Script started on Fri 21 Jun 2013 12:23:26 PM EDT
root@plbearer:/var/lib/xfstests# ./check -xfs xfs/111
FSTYP -- xfs (debug)
PLATFORM -- Linux/i686 plbearer 3.10.0-rc6+
MKFS_OPTIONS -- -f -llogdev=/dev/sda6 -bsize=4096 /dev/sdb6
MOUNT_OPTIONS -- -ologdev=/dev/sda6 /dev/sdb6 /mnt/xfstests-scratch
xfs/111 - output mismatch (see /var/lib/xfstests/results/xfs/111.out.bad)
--- tests/xfs/111.out 2013-06-21 12:19:39.085344653 -0400
+++ /var/lib/xfstests/results/xfs/111.out.bad 2013-06-21 12:23:53.762849921 -0400
@@ -6,6 +6,1006 @@
log =LDEV bsize=XXX blocks=XXX
realtime =RDEV extsz=XXX blocks=XXX, rtextents=XXX
Create some files
+cp: cannot stat 'src/itrash.c': No such file or directory
+cp: cannot stat 'src/itrash.c': No such file or directory
+cp: cannot stat 'src/itrash.c': No such file or directory
+cp: cannot stat 'src/itrash.c': No such file or directory
...
(Run 'diff -u tests/xfs/111.out /var/lib/xfstests/results/xfs/111.out.bad' to see the entire diff)
Ran: xfs/111
Failures: xfs/111
Failed 1 of 1 tests
root@plbearer:/var/lib/xfstests# dmesg
[ 1339.824439] XFS (sdb5): Mounting Filesystem
[ 1339.903058] XFS (sdb5): Ending clean mount
[ 1341.637015] XFS (sdb6): Mounting Filesystem
[ 1341.708437] XFS (sdb6): Ending clean mount
[ 1342.211400] XFS (sdb5): Mounting Filesystem
[ 1342.276526] XFS (sdb5): Ending clean mount
[ 1344.500213] XFS (sdb6): Mounting Filesystem
[ 1344.585894] XFS (sdb6): Ending clean mount
[ 1348.470883] XFS (sdb6): Mounting Filesystem
[ 1348.539515] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.539527] XFS (sdb6): bad inode magic/vsn daddr 64 #8 (magic=5858)
[ 1348.540856] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.540863] XFS (sdb6): bad inode magic/vsn daddr 64 #9 (magic=5858)
[ 1348.542140] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.542147] XFS (sdb6): bad inode magic/vsn daddr 64 #10 (magic=5858)
[ 1348.543394] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.543400] XFS (sdb6): bad inode magic/vsn daddr 64 #11 (magic=5858)
[ 1348.544627] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.544633] XFS (sdb6): bad inode magic/vsn daddr 64 #12 (magic=5858)
[ 1348.545854] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.545861] XFS (sdb6): bad inode magic/vsn daddr 64 #13 (magic=5858)
[ 1348.547017] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.547023] XFS (sdb6): bad inode magic/vsn daddr 64 #14 (magic=5858)
[ 1348.548176] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.548183] XFS (sdb6): bad inode magic/vsn daddr 64 #15 (magic=5858)
[ 1348.549328] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.549334] XFS (sdb6): bad inode magic/vsn daddr 64 #16 (magic=5858)
[ 1348.550484] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.550491] XFS (sdb6): bad inode magic/vsn daddr 64 #17 (magic=5858)
[ 1348.551582] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.551588] XFS (sdb6): bad inode magic/vsn daddr 64 #18 (magic=5858)
[ 1348.552694] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.552700] XFS (sdb6): bad inode magic/vsn daddr 64 #19 (magic=5858)
[ 1348.553780] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.553786] XFS (sdb6): bad inode magic/vsn daddr 64 #20 (magic=5858)
[ 1348.554855] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.554861] XFS (sdb6): bad inode magic/vsn daddr 64 #21 (magic=5858)
[ 1348.555927] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.555933] XFS (sdb6): bad inode magic/vsn daddr 64 #22 (magic=5858)
[ 1348.556989] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.556995] XFS (sdb6): bad inode magic/vsn daddr 64 #23 (magic=5858)
[ 1348.558037] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.558045] XFS (sdb6): bad inode magic/vsn daddr 64 #24 (magic=5858)
[ 1348.559075] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.559081] XFS (sdb6): bad inode magic/vsn daddr 64 #25 (magic=5858)
[ 1348.560139] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.560146] XFS (sdb6): bad inode magic/vsn daddr 64 #26 (magic=5858)
[ 1348.561164] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.561170] XFS (sdb6): bad inode magic/vsn daddr 64 #27 (magic=5858)
[ 1348.562169] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.562176] XFS (sdb6): bad inode magic/vsn daddr 64 #28 (magic=5858)
[ 1348.563152] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.563168] XFS (sdb6): bad inode magic/vsn daddr 64 #29 (magic=5858)
[ 1348.564125] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.564131] XFS (sdb6): bad inode magic/vsn daddr 64 #30 (magic=5858)
[ 1348.565065] XFS (sdb6): Corruption detected. Unmount and run xfs_repair
[ 1348.565072] XFS (sdb6): bad inode magic/vsn daddr 64 #31 (magic=5858)
[ 1348.566455] XFS (sdb6): metadata I/O error: block 0x40 ("xfs_trans_read_buf_map") error 117 numblks 16
[ 1348.566472] XFS (sdb6): xfs_imap_to_bp: xfs_trans_read_buf() returned error 117.
[ 1348.566484] XFS (sdb6): failed to read root inode
[ 1349.479741] XFS (sdb5): Mounting Filesystem
[ 1349.550037] XFS (sdb5): Ending clean mount
root@plbearer:/var/lib/xfstests# xfs_repair -l $SCRATCH_LOGDEV $SCRATCH_DEV
Phase 1 - find and verify superblock...
Phase 2 - using external log on /dev/sda6
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
xfs_inode_buf_verify: XFS_CORRUPTION_ERROR
bad magic number 0x5858 on inode 136
bad magic number 0x5858 on inode 137
bad magic number 0x5858 on inode 138
bad magic number 0x5858 on inode 139
bad magic number 0x5858 on inode 140
bad magic number 0x5858 on inode 141
bad magic number 0x5858 on inode 142
bad magic number 0x5858 on inode 143
bad magic number 0x5858 on inode 144
bad magic number 0x5858 on inode 145
bad magic number 0x5858 on inode 146
bad magic number 0x5858 on inode 147
bad magic number 0x5858 on inode 148
bad magic number 0x5858 on inode 149
bad magic number 0x5858 on inode 150
bad magic number 0x5858 on inode 151
bad magic number 0x5858 on inode 152
bad magic number 0x5858 on inode 153
bad magic number 0x5858 on inode 154
bad magic number 0x5858 on inode 155
bad magic number 0x5858 on inode 156
bad magic number 0x5858 on inode 157
bad magic number 0x5858 on inode 158
bad magic number 0x5858 on inode 159
bad magic number 0x5858 on inode 160
bad magic number 0x5858 on inode 161
bad magic number 0x5858 on inode 162
bad magic number 0x5858 on inode 163
bad magic number 0x5858 on inode 164
bad magic number 0x5858 on inode 165
bad magic number 0x5858 on inode 166
bad magic number 0x5858 on inode 167
bad magic number 0x5858 on inode 168
bad magic number 0x5858 on inode 169
bad magic number 0x5858 on inode 170
bad magic number 0x5858 on inode 171
bad magic number 0x5858 on inode 172
bad magic number 0x5858 on inode 173
bad magic number 0x5858 on inode 174
bad magic number 0x5858 on inode 175
bad magic number 0x5858 on inode 176
bad magic number 0x5858 on inode 177
bad magic number 0x5858 on inode 178
bad magic number 0x5858 on inode 179
bad magic number 0x5858 on inode 180
bad magic number 0x5858 on inode 181
bad magic number 0x5858 on inode 182
bad magic number 0x5858 on inode 183
bad magic number 0x5858 on inode 184
bad magic number 0x5858 on inode 185
bad magic number 0x5858 on inode 186
bad magic number 0x5858 on inode 187
bad magic number 0x5858 on inode 188
bad magic number 0x5858 on inode 189
bad magic number 0x5858 on inode 190
bad magic number 0x5858 on inode 191
bad magic number 0x5858 on inode 136, resetting magic number
bad magic number 0x5858 on inode 137, resetting magic number
bad magic number 0x5858 on inode 138, resetting magic number
bad magic number 0x5858 on inode 139, resetting magic number
bad magic number 0x5858 on inode 140, resetting magic number
bad magic number 0x5858 on inode 141, resetting magic number
bad magic number 0x5858 on inode 142, resetting magic number
bad magic number 0x5858 on inode 143, resetting magic number
bad magic number 0x5858 on inode 144, resetting magic number
bad magic number 0x5858 on inode 145, resetting magic number
bad magic number 0x5858 on inode 146, resetting magic number
bad magic number 0x5858 on inode 147, resetting magic number
bad magic number 0x5858 on inode 148, resetting magic number
bad magic number 0x5858 on inode 149, resetting magic number
bad magic number 0x5858 on inode 150, resetting magic number
bad magic number 0x5858 on inode 151, resetting magic number
bad magic number 0x5858 on inode 152, resetting magic number
bad magic number 0x5858 on inode 153, resetting magic number
bad magic number 0x5858 on inode 154, resetting magic number
bad magic number 0x5858 on inode 155, resetting magic number
bad magic number 0x5858 on inode 156, resetting magic number
bad magic number 0x5858 on inode 157, resetting magic number
bad magic number 0x5858 on inode 158, resetting magic number
bad magic number 0x5858 on inode 159, resetting magic number
bad magic number 0x5858 on inode 160, resetting magic number
bad magic number 0x5858 on inode 161, resetting magic number
bad magic number 0x5858 on inode 162, resetting magic number
bad magic number 0x5858 on inode 163, resetting magic number
bad magic number 0x5858 on inode 164, resetting magic number
bad magic number 0x5858 on inode 165, resetting magic number
bad magic number 0x5858 on inode 166, resetting magic number
bad magic number 0x5858 on inode 167, resetting magic number
bad magic number 0x5858 on inode 168, resetting magic number
bad magic number 0x5858 on inode 169, resetting magic number
bad magic number 0x5858 on inode 170, resetting magic number
bad magic number 0x5858 on inode 171, resetting magic number
bad magic number 0x5858 on inode 172, resetting magic number
bad magic number 0x5858 on inode 173, resetting magic number
bad magic number 0x5858 on inode 174, resetting magic number
bad magic number 0x5858 on inode 175, resetting magic number
bad magic number 0x5858 on inode 176, resetting magic number
bad magic number 0x5858 on inode 177, resetting magic number
bad magic number 0x5858 on inode 178, resetting magic number
bad magic number 0x5858 on inode 179, resetting magic number
bad magic number 0x5858 on inode 180, resetting magic number
bad magic number 0x5858 on inode 181, resetting magic number
bad magic number 0x5858 on inode 182, resetting magic number
bad magic number 0x5858 on inode 183, resetting magic number
bad magic number 0x5858 on inode 184, resetting magic number
bad magic number 0x5858 on inode 185, resetting magic number
bad magic number 0x5858 on inode 186, resetting magic number
bad magic number 0x5858 on inode 187, resetting magic number
bad magic number 0x5858 on inode 188, resetting magic number
bad magic number 0x5858 on inode 189, resetting magic number
bad magic number 0x5858 on inode 190, resetting magic number
bad magic number 0x5858 on inode 191, resetting magic number
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
xfs_imap_to_bp: xfs_trans_read_buf() returned error 117.
cache_node_purge: refcount was 1, not zero (node=0x937b600)
fatal error -- couldn't iget realtime bitmap inode -- error - 117
root@plbearer:/var/lib/xfstests# exit
Script done on Fri 21 Jun 2013 12:25:26 PM EDT
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: group for tests that are dangerous for verifiers?
2013-06-20 17:54 group for tests that are dangerous for verifiers? Mark Tinguely
2013-06-21 18:26 ` Michael L. Semon
@ 2013-06-21 18:45 ` Eric Sandeen
2013-06-23 22:50 ` Dave Chinner
1 sibling, 1 reply; 7+ messages in thread
From: Eric Sandeen @ 2013-06-21 18:45 UTC (permalink / raw)
To: Mark Tinguely; +Cc: xfs-oss
On 6/20/13 12:54 PM, Mark Tinguely wrote:
> Do we need a xfstest verifier dangerous group?
>
> xfstest 111 purposely damages inodes. In hindsight it make sense
> that it asserts when running with verifiers.
But it only asserts on a debug kernel...
This isn't the only place where corruption could ASSERT on debug;
see xlog_recover_add_to_trans() for example.
But if the test intentionally corrupts it and that leads to
an ASSERT that does seem problematic for anyone testing w/ debug
enabled.
I guess I'd vote for removing the ASSERT unless there's
some reason it should be there - Dave?
-Eric
> mkfs.xfs -f /dev/sda3
> meta-data=/dev/sda3 isize=256 agcount=4, agsize=4194496 blks
> = sectsz=512 attr=2, projid32bit=0
> data = bsize=4096 blocks=16777984, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0
> log =internal log bsize=4096 blocks=8192, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
>
> db/xfs_db /dev/sda3
> xfs_db> sb 0
> xfs_db> p
> magicnum = 0x58465342
> blocksize = 4096
> dblocks = 16777984
> rblocks = 0
> rextents = 0
> uuid = fd78c924-79c8-4cc4-af42-c5a8b505ab05
> logstart = 16777220
> rootino = 128
> rbmino = 129
> rsumino = 130
> rextsize = 1
> agblocks = 4194496
> agcount = 4
> rbmblocks = 0
> logblocks = 8192
> versionnum = 0xb4a4
> sectsize = 512
> inodesize = 256
> inopblock = 16
> fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
> blocklog = 12
> sectlog = 9
> inodelog = 8
> inopblog = 4
> agblklog = 23
> rextslog = 0
> inprogress = 0
> imax_pct = 25
> icount = 64
> ifree = 61
> fdblocks = 16769772
> frextents = 0
> uquotino = 0
> gquotino = 0
> qflags = 0
> flags = 0
> shared_vn = 0
> inoalignmt = 2
> unit = 0
> width = 0
> dirblklog = 0
> logsectlog = 0
> logsectsize = 0
> logsunit = 1
> features2 = 0xa
> bad_features2 = 0xa
>
> 72715.142266] XFS (sda3): Mounting Filesystem
> [72715.811778] XFS (sda3): Corruption detected. Unmount and run xfs_repair
> [72715.818396] XFS (sda3): bad inode magic/vsn daddr 64 #8 (magic=5858)
> [72715.824748] XFS: Assertion failed: 0, file: /root/xfs/fs/xfs/xfs_inode.c, line: 417
>
> PID: 271 TASK: ffff88034fb365c0 CPU: 1 COMMAND: "kworker/1:1H"
> #0 [ffff88034f407a10] machine_kexec at ffffffff8102a0c0
> #1 [ffff88034f407a60] crash_kexec at ffffffff810a4943
> #2 [ffff88034f407b30] oops_end at ffffffff8145dc10
> #3 [ffff88034f407b60] die at ffffffff81005693
> #4 [ffff88034f407b90] do_trap at ffffffff8145d583
> #5 [ffff88034f407bf0] do_invalid_op at ffffffff81002de0
> #6 [ffff88034f407c90] invalid_op at ffffffff81465ca8
> [exception RIP: assfail+29]
> RIP: ffffffffa04614dd RSP: ffff88034f407d48 RFLAGS: 00010296
> RAX: 0000000000000047 RBX: ffff88034dedc800 RCX: 0000000000000dda
> RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffffffff81a2dfc0
> RBP: ffff88034f407d48 R8: ffffffff81cd4848 R9: ffffffff81ce7003
> R10: 0000000000000068 R11: 000000000002d89c R12: 0000000000000008
> R13: ffff88034f57ee40 R14: ffff88034f0ba800 R15: 0000000000000020
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> #7 [ffff88034f407d50] xfs_inode_buf_verify at ffffffffa04aa400 [xfs]
> #8 [ffff88034f407db0] xfs_inode_buf_read_verify at ffffffffa04aa4b9 [xfs]
> #9 [ffff88034f407dc0] xfs_buf_iodone_work at ffffffffa044fd45 [xfs]
> #10 [ffff88034f407df0] process_one_work at ffffffff81059c8f
> #11 [ffff88034f407e50] worker_thread at ffffffff8105ad3b
> #12 [ffff88034f407ec0] kthread at ffffffff810612fb
> #13 [ffff88034f407f50] ret_from_fork at ffffffff81464b6c
>
>
> PID: 20866 TASK: ffff880351f24180 CPU: 1 COMMAND: "mount"
> #0 [ffff88035175f7c8] __schedule at ffffffff8145b6fe
> #1 [ffff88035175f850] schedule at ffffffff8145bb34
> #2 [ffff88035175f860] schedule_timeout at ffffffff81459bd5
> #3 [ffff88035175f910] wait_for_completion at ffffffff8145ac6d
> #4 [ffff88035175f970] xfs_buf_iowait at ffffffffa0450a09 [xfs]
> #5 [ffff88035175f9b0] _xfs_buf_read at ffffffffa0450bf9 [xfs]
> #6 [ffff88035175f9d0] xfs_buf_read_map at ffffffffa0450cf3 [xfs]
> #7 [ffff88035175fa20] xfs_trans_read_buf_map at ffffffffa04ca0e9 [xfs]
> #8 [ffff88035175fa90] xfs_imap_to_bp at ffffffffa04aa52b [xfs]
> #9 [ffff88035175fb10] xfs_iread at ffffffffa04b0e5d [xfs]
> #10 [ffff88035175fb80] xfs_iget_cache_miss at ffffffffa04586a0 [xfs]
> #11 [ffff88035175fbf0] xfs_iget at ffffffffa0459589 [xfs]
> #12 [ffff88035175fc80] xfs_mountfs at ffffffffa04bad49 [xfs]
> #13 [ffff88035175fcf0] xfs_fs_fill_super at ffffffffa0464ad7 [xfs]
> #14 [ffff88035175fd30] mount_bdev at ffffffff81155f85
> #15 [ffff88035175fdb0] xfs_fs_mount at ffffffffa04626d0 [xfs]
> #16 [ffff88035175fdc0] mount_fs at ffffffff81156bee
> #17 [ffff88035175fe10] vfs_kern_mount at ffffffff8116fe21
> #18 [ffff88035175fe60] do_new_mount at ffffffff8117136f
> #19 [ffff88035175fec0] do_mount at ffffffff811729b6
> #20 [ffff88035175ff20] sys_mount at ffffffff81172a8b
> #21 [ffff88035175ff80] system_call_fastpath at ffffffff81464c12
> RIP: 00007fbcdfd09daa RSP: 00007fffcb9f6f38 RFLAGS: 00010202
> RAX: 00000000000000a5 RBX: ffffffff81464c12 RCX: ffffffffffffffc8
> RDX: 00007fbce0a6ce80 RSI: 00007fbce0a6ce60 RDI: 00007fbce0a6ce40
> RBP: 00000000c0ed0400 R8: 0000000000000000 R9: 0101010101010101
> R10: ffffffffc0ed0400 R11: 0000000000000202 R12: 00007fbce0a6ce60
> R13: 00007fbce0a6cde0 R14: 0000000000000400 R15: 0000000000000000
> ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b
>
> _______________________________________________
> 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] 7+ messages in thread
* Re: group for tests that are dangerous for verifiers?
2013-06-21 18:45 ` Eric Sandeen
@ 2013-06-23 22:50 ` Dave Chinner
2013-06-23 22:57 ` Eric Sandeen
0 siblings, 1 reply; 7+ messages in thread
From: Dave Chinner @ 2013-06-23 22:50 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Mark Tinguely, xfs-oss
On Fri, Jun 21, 2013 at 01:45:46PM -0500, Eric Sandeen wrote:
> On 6/20/13 12:54 PM, Mark Tinguely wrote:
> > Do we need a xfstest verifier dangerous group?
> >
> > xfstest 111 purposely damages inodes. In hindsight it make sense
> > that it asserts when running with verifiers.
>
> But it only asserts on a debug kernel...
Right, and it has done so for years - blaming verifiers for
triggering the assert failure is simply shooting the messenger.
> This isn't the only place where corruption could ASSERT on debug;
> see xlog_recover_add_to_trans() for example.
>
> But if the test intentionally corrupts it and that leads to
> an ASSERT that does seem problematic for anyone testing w/ debug
> enabled.
Yup, it runs src/itrash.c which corrupts every inode it can find.
That's the reason this test is not part of the auto group - it's
a test that will cause the system to stop. We've got other tests
that are not part of the auto group for exactly the same reason -
they cause some kind of terminal failure and so aren't candidates
for regression testing.
> I guess I'd vote for removing the ASSERT unless there's
> some reason it should be there - Dave?
I'm fine with it being removed - we catch the failure just fine. If
that then makes 111 work as a regression test (i.e. doesn't trigger
the bad-inode bulkstat loop it was designed to test) then perhaps we
can consider making that part of the auto group, too...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: group for tests that are dangerous for verifiers?
2013-06-23 22:50 ` Dave Chinner
@ 2013-06-23 22:57 ` Eric Sandeen
2013-06-23 23:44 ` Dave Chinner
0 siblings, 1 reply; 7+ messages in thread
From: Eric Sandeen @ 2013-06-23 22:57 UTC (permalink / raw)
To: Dave Chinner; +Cc: Mark Tinguely, xfs-oss
On 6/23/13 5:50 PM, Dave Chinner wrote:
> On Fri, Jun 21, 2013 at 01:45:46PM -0500, Eric Sandeen wrote:
>> On 6/20/13 12:54 PM, Mark Tinguely wrote:
>>> Do we need a xfstest verifier dangerous group?
>>>
>>> xfstest 111 purposely damages inodes. In hindsight it make sense
>>> that it asserts when running with verifiers.
>>
>> But it only asserts on a debug kernel...
>
> Right, and it has done so for years - blaming verifiers for
> triggering the assert failure is simply shooting the messenger.
But this test *intentionally* corrupts, right? So it's prudent
to not run a test which you *know* will explode if it runs
as designed.
>> This isn't the only place where corruption could ASSERT on debug;
>> see xlog_recover_add_to_trans() for example.
>>
>> But if the test intentionally corrupts it and that leads to
>> an ASSERT that does seem problematic for anyone testing w/ debug
>> enabled.
>
> Yup, it runs src/itrash.c which corrupts every inode it can find.
>
> That's the reason this test is not part of the auto group - it's
> a test that will cause the system to stop. We've got other tests
> that are not part of the auto group for exactly the same reason -
> they cause some kind of terminal failure and so aren't candidates
> for regression testing.
Then maybe just part of the normal dangerous group would be enough.
Except this isn't transient (today) - it's not a case where old kernels
may oops, it's where it's *designed* to oops on this test, with a debug
kernel.
So I guess I could see a debug-dangerous group ;)
>> I guess I'd vote for removing the ASSERT unless there's
>> some reason it should be there - Dave?
>
> I'm fine with it being removed - we catch the failure just fine. If
> that then makes 111 work as a regression test (i.e. doesn't trigger
> the bad-inode bulkstat loop it was designed to test) then perhaps we
> can consider making that part of the auto group, too...
Removing it sounds like the best option then.
Thanks,
-Eric
> Cheers,
>
> Dave.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: group for tests that are dangerous for verifiers?
2013-06-23 22:57 ` Eric Sandeen
@ 2013-06-23 23:44 ` Dave Chinner
2013-06-24 13:50 ` Mark Tinguely
0 siblings, 1 reply; 7+ messages in thread
From: Dave Chinner @ 2013-06-23 23:44 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Mark Tinguely, xfs-oss
On Sun, Jun 23, 2013 at 05:57:49PM -0500, Eric Sandeen wrote:
> On 6/23/13 5:50 PM, Dave Chinner wrote:
> > On Fri, Jun 21, 2013 at 01:45:46PM -0500, Eric Sandeen wrote:
> >> On 6/20/13 12:54 PM, Mark Tinguely wrote:
> >>> Do we need a xfstest verifier dangerous group?
> >>>
> >>> xfstest 111 purposely damages inodes. In hindsight it make sense
> >>> that it asserts when running with verifiers.
> >>
> >> But it only asserts on a debug kernel...
> >
> > Right, and it has done so for years - blaming verifiers for
> > triggering the assert failure is simply shooting the messenger.
>
> But this test *intentionally* corrupts, right? So it's prudent
> to not run a test which you *know* will explode if it runs
> as designed.
Common sense, really.
> >> This isn't the only place where corruption could ASSERT on debug;
> >> see xlog_recover_add_to_trans() for example.
> >>
> >> But if the test intentionally corrupts it and that leads to
> >> an ASSERT that does seem problematic for anyone testing w/ debug
> >> enabled.
> >
> > Yup, it runs src/itrash.c which corrupts every inode it can find.
> >
> > That's the reason this test is not part of the auto group - it's
> > a test that will cause the system to stop. We've got other tests
> > that are not part of the auto group for exactly the same reason -
> > they cause some kind of terminal failure and so aren't candidates
> > for regression testing.
>
> Then maybe just part of the normal dangerous group would be enough.
It will only run from the ioctl group today (bulkstat, I guess), so
I'd say that adding it to the dangerous group doesn't add any real
value except documentation. And it's just as easy to remove the
ASSERT() as it is really unnecessary....
> Except this isn't transient (today) - it's not a case where old kernels
> may oops, it's where it's *designed* to oops on this test, with a debug
> kernel.
>
> So I guess I could see a debug-dangerous group ;)
>
> >> I guess I'd vote for removing the ASSERT unless there's
> >> some reason it should be there - Dave?
> >
> > I'm fine with it being removed - we catch the failure just fine. If
> > that then makes 111 work as a regression test (i.e. doesn't trigger
> > the bad-inode bulkstat loop it was designed to test) then perhaps we
> > can consider making that part of the auto group, too...
>
> Removing it sounds like the best option then.
*nod*
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: group for tests that are dangerous for verifiers?
2013-06-23 23:44 ` Dave Chinner
@ 2013-06-24 13:50 ` Mark Tinguely
0 siblings, 0 replies; 7+ messages in thread
From: Mark Tinguely @ 2013-06-24 13:50 UTC (permalink / raw)
To: Dave Chinner; +Cc: Eric Sandeen, xfs-oss
On 06/23/13 18:44, Dave Chinner wrote:
> On Sun, Jun 23, 2013 at 05:57:49PM -0500, Eric Sandeen wrote:
>> On 6/23/13 5:50 PM, Dave Chinner wrote:
>>> On Fri, Jun 21, 2013 at 01:45:46PM -0500, Eric Sandeen wrote:
>>>> On 6/20/13 12:54 PM, Mark Tinguely wrote:
>>>>> Do we need a xfstest verifier dangerous group?
>>>>>
>>>>> xfstest 111 purposely damages inodes. In hindsight it make sense
>>>>> that it asserts when running with verifiers.
>>>>
>>>> But it only asserts on a debug kernel...
>>>
>>> Right, and it has done so for years - blaming verifiers for
>>> triggering the assert failure is simply shooting the messenger.
>>
>> But this test *intentionally* corrupts, right? So it's prudent
>> to not run a test which you *know* will explode if it runs
>> as designed.
>
> Common sense, really.
... and the reason for the open question. Should there be a group
notation that says the verifiers will *correctly* find a real and known
problem on this test.
>
>>>> This isn't the only place where corruption could ASSERT on debug;
>>>> see xlog_recover_add_to_trans() for example.
>>>>
>>>> But if the test intentionally corrupts it and that leads to
>>>> an ASSERT that does seem problematic for anyone testing w/ debug
>>>> enabled.
>>>
>>> Yup, it runs src/itrash.c which corrupts every inode it can find.
>>>
>>> That's the reason this test is not part of the auto group - it's
>>> a test that will cause the system to stop. We've got other tests
>>> that are not part of the auto group for exactly the same reason -
>>> they cause some kind of terminal failure and so aren't candidates
>>> for regression testing.
>>
>> Then maybe just part of the normal dangerous group would be enough.
>
> It will only run from the ioctl group today (bulkstat, I guess), so
> I'd say that adding it to the dangerous group doesn't add any real
> value except documentation. And it's just as easy to remove the
> ASSERT() as it is really unnecessary....
>
>> Except this isn't transient (today) - it's not a case where old kernels
>> may oops, it's where it's *designed* to oops on this test, with a debug
>> kernel.
>>
>> So I guess I could see a debug-dangerous group ;)
>>
>>>> I guess I'd vote for removing the ASSERT unless there's
>>>> some reason it should be there - Dave?
>>>
>>> I'm fine with it being removed - we catch the failure just fine. If
>>> that then makes 111 work as a regression test (i.e. doesn't trigger
>>> the bad-inode bulkstat loop it was designed to test) then perhaps we
>>> can consider making that part of the auto group, too...
>>
>> Removing it sounds like the best option then.
>
> *nod*
>
That works too.
Thanks,
--Mark.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-06-24 13:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-20 17:54 group for tests that are dangerous for verifiers? Mark Tinguely
2013-06-21 18:26 ` Michael L. Semon
2013-06-21 18:45 ` Eric Sandeen
2013-06-23 22:50 ` Dave Chinner
2013-06-23 22:57 ` Eric Sandeen
2013-06-23 23:44 ` Dave Chinner
2013-06-24 13:50 ` Mark Tinguely
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox