All of lore.kernel.org
 help / color / mirror / Atom feed
* xfs errors while unlinking filenames with hash collisions
@ 2014-03-27  7:41 Hannes Frederic Sowa
  2014-03-27 13:14 ` Mark Tinguely
  2014-04-01 18:49 ` [PATCH xfstests] tests for file hash collisions on xfs filesystems Hannes Frederic Sowa
  0 siblings, 2 replies; 16+ messages in thread
From: Hannes Frederic Sowa @ 2014-03-27  7:41 UTC (permalink / raw)
  To: xfs

Hello!

I wanted to break some network stack hashing, but while running the test
against my local xfs filesystem I got corruptions in rmdir:

[ 3856.245843] XFS (vda1): Internal error xfs_trans_cancel at line 966 of file fs/xfs/xfs_trans.c.  Caller 0xffffffffa01186bc
[ 3856.249049] CPU: 1 PID: 866 Comm: rm Not tainted 3.13.6-200.fc20.x86_64 #1
[ 3856.250966] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 3856.252615]  000000000000000c ffff8800d23a7d68 ffffffff8168730c ffff8800cf5462b8
[ 3856.254823]  ffff8800d23a7d80 ffffffffa00d00cb ffffffffa01186bc ffff8800d23a7da8
[ 3856.257241]  ffffffffa00e5459 ffff8800d9ac3400 ffff8800d23a7e30 ffff8800371b6800
[ 3856.259420] Call Trace:
[ 3856.260172]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[ 3856.261717]  [<ffffffffa00d00cb>] xfs_error_report+0x3b/0x40 [xfs]
[ 3856.263472]  [<ffffffffa01186bc>] ? xfs_remove+0x1ac/0x370 [xfs]
[ 3856.270838]  [<ffffffffa00e5459>] xfs_trans_cancel+0xd9/0x100 [xfs]
[ 3856.272783]  [<ffffffffa01186bc>] xfs_remove+0x1ac/0x370 [xfs]
[ 3856.274531]  [<ffffffffa00db40b>] xfs_vn_unlink+0x4b/0x90 [xfs]
[ 3856.276286]  [<ffffffff811c61b8>] vfs_rmdir+0xa8/0x100
[ 3856.277821]  [<ffffffff811c638d>] do_rmdir+0x17d/0x1d0
[ 3856.281021]  [<ffffffff811ba7fe>] ? ____fput+0xe/0x10
[ 3856.285261]  [<ffffffff8108c11c>] ? task_work_run+0xac/0xe0
[ 3856.286952]  [<ffffffff81013a31>] ? do_notify_resume+0x61/0xa0
[ 3856.288693]  [<ffffffff811c9a65>] SyS_unlinkat+0x25/0x40
[ 3856.290407]  [<ffffffff816962e9>] system_call_fastpath+0x16/0x1b
[ 3856.292685] XFS (vda1): xfs_do_force_shutdown(0x8) called from line 967 of file fs/xfs/xfs_trans.c.  Return address = 0xffffffffa00e5472
[ 3856.627330] XFS (vda1): Corruption of in-memory data detected.  Shutting down filesystem
[ 3856.627332] XFS (vda1): Please umount the filesystem and rectify the problem(s)

I also tested this on a current linux net-next kernel, which is 3.14.0-rc6.

If I run the test code below in an directory for a while and after that
try to unlink the files in it (rm -rf testdir), I get above splat. Even
after running xfs_repair I cannot remove the directory. The system is
pretty unusable after that if this is done on a root filesystem.

I quickly extracted this simple test case below. It does not generate
perfect collisions, but they are enough to trigger the above described
problem.

Thanks,

  Hannes

---- >8 ----
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdbool.h>
#include <unistd.h>
#include <err.h>
#include <string.h>
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <limits.h>

static inline uint32_t rol32(uint32_t word, unsigned int shift)
{
	return (word << shift) | (word >> (32 - shift));
}

static uint32_t xfs_hash(const uint8_t *name, int namelen)
{
	uint32_t hash = 0;

	for (; namelen >= 4; namelen -= 4, name += 4)
		hash = (name[0] << 21) ^ (name[1] << 14) ^ (name[2] << 7) ^ (name[3] << 0) ^ rol32(hash, 7 * 4);

	if (namelen)
		abort();

	return hash;
}

static uint8_t gen_rand(void)
{
	uint8_t r;
	while (!(r = rand()));
	return r;
}

static uint8_t *round_one(uint8_t (*generator)())
{
	int idx;
	static uint8_t buffer[300] = {0};

	for (idx = 0; idx < 252-4; idx+=4) {
		buffer[idx + 0] = gen_rand();
		buffer[idx + 1] = gen_rand();
		buffer[idx + 2] = gen_rand();
		buffer[idx + 3] = gen_rand();
	}
	return buffer;
}

static uint8_t *round_two(uint8_t *buffer)
{
	static uint8_t a = 0, b = 0, c = 0;

	static const uint32_t target = ~0U;

	uint32_t hash = rol32(xfs_hash(buffer, 248), 7 * 4);

	a++, b++, c++;

	uint32_t last = hash ^ target;

	buffer[248] = (last >> 21) & 0xff;
	buffer[249] = (last >> 14) & 0xff;
	buffer[250] = (last >> 7) & 0xff;
	buffer[251] = last & 0xff;

	return buffer;
}

int main(int argc, char **argv)
{
	unsigned int cnt = 0;

	while (true)
		mkdir(round_two(round_one(gen_rand)), S_IRWXU);

	exploit();
}
--- >8 ----

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27  7:41 xfs errors while unlinking filenames with hash collisions Hannes Frederic Sowa
@ 2014-03-27 13:14 ` Mark Tinguely
  2014-03-27 13:23   ` Hannes Frederic Sowa
  2014-04-01 18:49 ` [PATCH xfstests] tests for file hash collisions on xfs filesystems Hannes Frederic Sowa
  1 sibling, 1 reply; 16+ messages in thread
From: Mark Tinguely @ 2014-03-27 13:14 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: xfs

On 03/27/14 02:41, Hannes Frederic Sowa wrote:
> Hello!
>
> I wanted to break some network stack hashing, but while running the test
> against my local xfs filesystem I got corruptions in rmdir:
>
> [ 3856.245843] XFS (vda1): Internal error xfs_trans_cancel at line 966 of file fs/xfs/xfs_trans.c.  Caller 0xffffffffa01186bc
> [ 3856.249049] CPU: 1 PID: 866 Comm: rm Not tainted 3.13.6-200.fc20.x86_64 #1
> [ 3856.250966] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 3856.252615]  000000000000000c ffff8800d23a7d68 ffffffff8168730c ffff8800cf5462b8
> [ 3856.254823]  ffff8800d23a7d80 ffffffffa00d00cb ffffffffa01186bc ffff8800d23a7da8
> [ 3856.257241]  ffffffffa00e5459 ffff8800d9ac3400 ffff8800d23a7e30 ffff8800371b6800
> [ 3856.259420] Call Trace:
> [ 3856.260172]  [<ffffffff8168730c>] dump_stack+0x45/0x56
> [ 3856.261717]  [<ffffffffa00d00cb>] xfs_error_report+0x3b/0x40 [xfs]
> [ 3856.263472]  [<ffffffffa01186bc>] ? xfs_remove+0x1ac/0x370 [xfs]
> [ 3856.270838]  [<ffffffffa00e5459>] xfs_trans_cancel+0xd9/0x100 [xfs]
> [ 3856.272783]  [<ffffffffa01186bc>] xfs_remove+0x1ac/0x370 [xfs]
> [ 3856.274531]  [<ffffffffa00db40b>] xfs_vn_unlink+0x4b/0x90 [xfs]
> [ 3856.276286]  [<ffffffff811c61b8>] vfs_rmdir+0xa8/0x100
> [ 3856.277821]  [<ffffffff811c638d>] do_rmdir+0x17d/0x1d0
> [ 3856.281021]  [<ffffffff811ba7fe>] ? ____fput+0xe/0x10
> [ 3856.285261]  [<ffffffff8108c11c>] ? task_work_run+0xac/0xe0
> [ 3856.286952]  [<ffffffff81013a31>] ? do_notify_resume+0x61/0xa0
> [ 3856.288693]  [<ffffffff811c9a65>] SyS_unlinkat+0x25/0x40
> [ 3856.290407]  [<ffffffff816962e9>] system_call_fastpath+0x16/0x1b
> [ 3856.292685] XFS (vda1): xfs_do_force_shutdown(0x8) called from line 967 of file fs/xfs/xfs_trans.c.  Return address = 0xffffffffa00e5472
> [ 3856.627330] XFS (vda1): Corruption of in-memory data detected.  Shutting down filesystem
> [ 3856.627332] XFS (vda1): Please umount the filesystem and rectify the problem(s)
>
> I also tested this on a current linux net-next kernel, which is 3.14.0-rc6.
>
> If I run the test code below in an directory for a while and after that
> try to unlink the files in it (rm -rf testdir), I get above splat. Even
> after running xfs_repair I cannot remove the directory. The system is
> pretty unusable after that if this is done on a root filesystem.
>
> I quickly extracted this simple test case below. It does not generate
> perfect collisions, but they are enough to trigger the above described
> problem.
>
> Thanks,
>
>    Hannes
>

Have you tried to run a xfs_repair on the filesystem after the reboot?

Do you fill the filesystem with the test or just part way?

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 13:14 ` Mark Tinguely
@ 2014-03-27 13:23   ` Hannes Frederic Sowa
  2014-03-27 13:34     ` Mark Tinguely
  0 siblings, 1 reply; 16+ messages in thread
From: Hannes Frederic Sowa @ 2014-03-27 13:23 UTC (permalink / raw)
  To: Mark Tinguely; +Cc: xfs

On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
> Have you tried to run a xfs_repair on the filesystem after the reboot?

Yes, I did. I still use the filesystem and it works. As soon as I try to
remove the directory again the same splash from above happens again.

> Do you fill the filesystem with the test or just part way?

Just part way. The problem certainly appears with 100_000 created directories.

Greetings,

  Hannes

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 13:23   ` Hannes Frederic Sowa
@ 2014-03-27 13:34     ` Mark Tinguely
  2014-03-27 14:05       ` Hannes Frederic Sowa
  0 siblings, 1 reply; 16+ messages in thread
From: Mark Tinguely @ 2014-03-27 13:34 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: xfs

On 03/27/14 08:23, Hannes Frederic Sowa wrote:
> On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
>> Have you tried to run a xfs_repair on the filesystem after the reboot?
>
> Yes, I did. I still use the filesystem and it works. As soon as I try to
> remove the directory again the same splash from above happens again.

Is it the latest xfsprogs' repair?

Do you have the output from the repair still?


>> Do you fill the filesystem with the test or just part way?
>
> Just part way. The problem certainly appears with 100_000 created directories.
>
> Greetings,
>
>    Hannes


okay thanks.

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 13:34     ` Mark Tinguely
@ 2014-03-27 14:05       ` Hannes Frederic Sowa
  2014-03-27 15:15         ` Mark Tinguely
  0 siblings, 1 reply; 16+ messages in thread
From: Hannes Frederic Sowa @ 2014-03-27 14:05 UTC (permalink / raw)
  To: Mark Tinguely; +Cc: xfs

On Thu, Mar 27, 2014 at 08:34:14AM -0500, Mark Tinguely wrote:
> On 03/27/14 08:23, Hannes Frederic Sowa wrote:
> >On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
> >>Have you tried to run a xfs_repair on the filesystem after the reboot?
> >
> >Yes, I did. I still use the filesystem and it works. As soon as I try to
> >remove the directory again the same splash from above happens again.
> 
> Is it the latest xfsprogs' repair?
> 
> Do you have the output from the repair still?

I can easily test this here, so you can throw any commands and tests at
me. ;)

This is the output:

(I replayed the journal before that)

pre-mount:/# xfs_repair -V
xfs_repair version 3.1.11
pre-mount:/# xfs_repair -v /dev/vda1 
Phase 1 - find and verify superblock...
        - block cache size set to 372848 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 5071 tail block 5071
        - 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
bad hash ordering in block 8388739 of directory inode 3543184
        - 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...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - agno = 0
rebuilding directory inode 3543184
        - agno = 1
        - agno = 2
        - agno = 3
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...

        XFS_REPAIR Summary    Thu Mar 27 14:03:12 2014

Phase		Start		End		Duration
Phase 1:	03/27 14:02:42	03/27 14:02:42	
Phase 2:	03/27 14:02:42	03/27 14:02:42	
Phase 3:	03/27 14:02:42	03/27 14:02:45	3 seconds
Phase 4:	03/27 14:02:45	03/27 14:02:46	1 second
Phase 5:	03/27 14:02:46	03/27 14:02:46	
Phase 6:	03/27 14:02:46	03/27 14:03:10	24 seconds
Phase 7:	03/27 14:03:10	03/27 14:03:10	

Total run time: 28 seconds
done

Some other time I remembered getting directory names printed to the serial
console, which got killed because of this. This time it didn't happen.

Btw., When tried to remove the old directory without generating a new
poison one, I got some other traces. Seems like the above splash only
happens when I create and try to remove the directories in one run
(without reboot between).

[   23.401494] ffff88011898e000: 00 00 00 00 00 00 00 00 d2 f1 00 00 01 4d 00 92  .............M..
[   23.408565] ffff88011898e010: 00 00 00 2e 00 00 00 02 00 00 17 2e 00 00 00 04  ................
[   23.423819] ffff88011898e020: 14 10 19 e2 00 02 bc 02 14 10 19 e2 00 02 c2 a7  ................
[   23.430293] ffff88011898e030: 14 10 19 e2 00 02 c5 d0 14 10 19 e2 00 02 c4 c8  ................
[   23.433952] XFS (vda1): Internal error __read_verify at line 186 of file fs/xfs/xfs_dir2_leaf.c.  Caller 0xffffffffa010c243
[   23.439316] CPU: 1 PID: 178 Comm: kworker/1:1H Not tainted 3.13.6-200.fc20.x86_64 #1
[   23.442614] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   23.445069] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[   23.447307]  0000000000000001 ffff8800db7bbd50 ffffffff8168730c ffff8800db97a000
[   23.453139]  ffff8800db7bbd68 ffffffffa00d10cb ffffffffa010c243 ffff8800db7bbda0
[   23.465312]  ffffffffa00d1125 000000badb7bbda0 ffff880117dd8600 ffff8800db97a000
[   23.468831] Call Trace:
[   23.469950]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[   23.472269]  [<ffffffffa00d10cb>] xfs_error_report+0x3b/0x40 [xfs]
[   23.475774]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.480877]  [<ffffffffa00d1125>] xfs_corruption_error+0x55/0x80 [xfs]
[   23.483665]  [<ffffffffa010c1b6>] __read_verify+0x76/0xf0 [xfs]
[   23.486227]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.489715]  [<ffffffffa010c243>] xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.492707]  [<ffffffffa00ce245>] xfs_buf_iodone_work+0x85/0xf0 [xfs]
[   23.495499]  [<ffffffff81087b76>] process_one_work+0x176/0x430
[   23.499170]  [<ffffffff810887ab>] worker_thread+0x11b/0x3a0
[   23.502038]  [<ffffffff81088690>] ? rescuer_thread+0x350/0x350
[   23.505033]  [<ffffffff8108f272>] kthread+0xd2/0xf0
[   23.507504]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   23.510573]  [<ffffffff8169623c>] ret_from_fork+0x7c/0xb0
[   23.513104]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   23.515687] XFS (vda1): Corruption detected. Unmount and run xfs_repair
[   23.520994] XFS (vda1): metadata I/O error: block 0x1212dd0 ("xfs_trans_read_buf_map") error 117 numblks 8
[   23.521674] ffff88011898e000: 00 00 00 00 00 00 00 00 d2 f1 00 00 01 4d 00 92  .............M..
[   23.521676] ffff88011898e010: 00 00 00 2e 00 00 00 02 00 00 17 2e 00 00 00 04  ................
[   23.521677] ffff88011898e020: 14 10 19 e2 00 02 bc 02 14 10 19 e2 00 02 c2 a7  ................
[   23.521678] ffff88011898e030: 14 10 19 e2 00 02 c5 d0 14 10 19 e2 00 02 c4 c8  ................
[   23.521682] XFS (vda1): Internal error __read_verify at line 186 of file fs/xfs/xfs_dir2_leaf.c.  Caller 0xffffffffa010c243
[   23.521685] CPU: 1 PID: 178 Comm: kworker/1:1H Not tainted 3.13.6-200.fc20.x86_64 #1
[   23.521685] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   23.521731] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[   23.521734]  0000000000000001 ffff8800db7bbd50 ffffffff8168730c ffff8800db97a000
[   23.521736]  ffff8800db7bbd68 ffffffffa00d10cb ffffffffa010c243 ffff8800db7bbda0
[   23.521738]  ffffffffa00d1125 000000badb7bbda0 ffff880117dd8600 ffff8800db97a000
[   23.521738] Call Trace:
[   23.521745]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[   23.521764]  [<ffffffffa00d10cb>] xfs_error_report+0x3b/0x40 [xfs]
[   23.521788]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.521806]  [<ffffffffa00d1125>] xfs_corruption_error+0x55/0x80 [xfs]
[   23.521829]  [<ffffffffa010c1b6>] __read_verify+0x76/0xf0 [xfs]
[   23.521852]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.521875]  [<ffffffffa010c243>] xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.521893]  [<ffffffffa00ce245>] xfs_buf_iodone_work+0x85/0xf0 [xfs]
[   23.521896]  [<ffffffff81087b76>] process_one_work+0x176/0x430
[   23.521898]  [<ffffffff810887ab>] worker_thread+0x11b/0x3a0
[   23.521900]  [<ffffffff81088690>] ? rescuer_thread+0x350/0x350
[   23.521902]  [<ffffffff8108f272>] kthread+0xd2/0xf0
[   23.521905]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   23.521908]  [<ffffffff8169623c>] ret_from_fork+0x7c/0xb0
[   23.521910]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   23.521911] XFS (vda1): Corruption detected. Unmount and run xfs_repair
[   23.522053] XFS (vda1): metadata I/O error: block 0x1212dd0 ("xfs_trans_read_buf_map") error 117 numblks 8
[   23.767676] ffff88011898e000: 00 00 00 00 00 00 00 00 d2 f1 00 00 01 4d 00 92  .............M..
[   23.767677] ffff88011898e010: 00 00 00 2e 00 00 00 02 00 00 17 2e 00 00 00 04  ................
[   23.767678] ffff88011898e020: 14 10 19 e2 00 02 bc 02 14 10 19 e2 00 02 c2 a7  ................
[   23.767680] ffff88011898e030: 14 10 19 e2 00 02 c5 d0 14 10 19 e2 00 02 c4 c8  ................
[   23.767683] XFS (vda1): Internal error __read_verify at line 186 of file fs/xfs/xfs_dir2_leaf.c.  Caller 0xffffffffa010c243
[   23.767686] CPU: 1 PID: 178 Comm: kworker/1:1H Not tainted 3.13.6-200.fc20.x86_64 #1
[   23.767686] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   23.767731] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[   23.767734]  0000000000000001 ffff8800db7bbd50 ffffffff8168730c ffff8800db97a000
[   23.767736]  ffff8800db7bbd68 ffffffffa00d10cb ffffffffa010c243 ffff8800db7bbda0
[   23.767737]  ffffffffa00d1125 000000badb7bbda0 ffff880117dd8600 ffff8800db97a000
[   23.767738] Call Trace:
[   23.767744]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[   23.767763]  [<ffffffffa00d10cb>] xfs_error_report+0x3b/0x40 [xfs]
[   23.767840]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.767860]  [<ffffffffa00d1125>] xfs_corruption_error+0x55/0x80 [xfs]
[   23.767884]  [<ffffffffa010c1b6>] __read_verify+0x76/0xf0 [xfs]
[   23.767908]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.767931]  [<ffffffffa010c243>] xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.767950]  [<ffffffffa00ce245>] xfs_buf_iodone_work+0x85/0xf0 [xfs]
[   23.767954]  [<ffffffff81087b76>] process_one_work+0x176/0x430
[   23.767956]  [<ffffffff810887ab>] worker_thread+0x11b/0x3a0
[   23.767958]  [<ffffffff81088690>] ? rescuer_thread+0x350/0x350
[   23.767961]  [<ffffffff8108f272>] kthread+0xd2/0xf0
[   23.767963]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   23.767966]  [<ffffffff8169623c>] ret_from_fork+0x7c/0xb0
[   23.767969]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   23.768005] XFS (vda1): Corruption detected. Unmount and run xfs_repair
[   23.768191] XFS (vda1): metadata I/O error: block 0x1212dd0 ("xfs_trans_read_buf_map") error 117 numblks 8
[   23.768665] ffff8800d7fd2000: 00 00 00 00 00 00 00 00 d2 f1 00 00 01 4d 00 92  .............M..
[   23.768666] ffff8800d7fd2010: 00 00 00 2e 00 00 00 02 00 00 17 2e 00 00 00 04  ................
[   23.768667] ffff8800d7fd2020: 14 10 19 e2 00 02 bc 02 14 10 19 e2 00 02 c2 a7  ................
[   23.768668] ffff8800d7fd2030: 14 10 19 e2 00 02 c5 d0 14 10 19 e2 00 02 c4 c8  ................
[   23.768671] XFS (vda1): Internal error __read_verify at line 186 of file fs/xfs/xfs_dir2_leaf.c.  Caller 0xffffffffa010c243
[   23.768673] CPU: 1 PID: 178 Comm: kworker/1:1H Not tainted 3.13.6-200.fc20.x86_64 #1
[   23.768674] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   23.768706] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[   23.768709]  0000000000000001 ffff8800db7bbd50 ffffffff8168730c ffff8800db97a000
[   23.768710]  ffff8800db7bbd68 ffffffffa00d10cb ffffffffa010c243 ffff8800db7bbda0
[   23.768712]  ffffffffa00d1125 000000badb7bbda0 ffff880117dd8600 ffff8800db97a000
[   23.768712] Call Trace:
[   23.768718]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[   23.768737]  [<ffffffffa00d10cb>] xfs_error_report+0x3b/0x40 [xfs]
[   23.768761]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.768887]  [<ffffffffa00d1125>] xfs_corruption_error+0x55/0x80 [xfs]
[   23.768911]  [<ffffffffa010c1b6>] __read_verify+0x76/0xf0 [xfs]
[   23.768934]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.768957]  [<ffffffffa010c243>] xr+0x55/0x80 [xfs]
[   23.864331]  [<ffffffffa010c1b6>] __read_verify+0x76/0xf0 [xfs]
[   23.864353]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.864376]  [<ffffffffa010c243>] xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   23.864393]  [<ffffffffa00ce245>] xfs_buf_iodone_work+0x85/0xf0 [xfs]
[   23.864417]  [<ffffffff81087b76>] process_one_work+0x176/0x430
[   23.864419]  [<ffffffff810887ab>] worker_thread+0x11b/0x3a0
[   23.864421]  [<ffffffff81088690>] ? rescuer_thread+0x350/0x350
[   23.864423]  [<ffffffff8108f272>] kthread+0xd2/0xf0
[   23.864426]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   23.864428]  [<ffffffff8169623c>] ret_from_fork+0x7c/0xb0
[   23.864430]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   23.864432] XFS (vda1): Corruption detected. Unmount and run xfs_repair
[   23.865270] XFS (vda1): metadata I/O error: block 0x1212dd0 ("xfs_trans_read_buf_map") error 117 numblks 8
[   23.929267] ffff8800d7fd2000: 00 00 00 00 00 00 00 00 d2 f1 00 00 01 4d 00 92  .............M..
[   23.929269] ffff8800d7fd2010: 00 00 00 2e 00 00 00 02 00 00 17 2e 00 00 00 04  ................
[   23.929270] ffff8800d7fd2020: 14 10 19 e2 00 02 bc 02 14 10 19 e2 00 02 c2 a7  ................
[   23.929271] ffff8800d7fd2030: 14 10 19 e2 00 02 c5 d0 14 10 19 e2 00 02 c4 c8  ................
[   23.929274] XFS (vda1): Internal error __read_verify at line 186 of file fs/xfs/xfs_dir2_leaf.c.  Caller 0xffffffffa010c243
[   23.929277] CPU: 1 PID: 178 Comm: kworker/1:1H Not tainted 3.13.6-200.fc20.x86_64 #1
[   23.929278] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   23.929323] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[   23.929325]  0000000000000001 ffff8800db7bbd50 ffffffff8168730c ffff8800db97a000
[   23.929327]  ffff8800db7bbd68 ffffffffa00d10cb ffffffffa010c243 ffff8800db7bbda0
[   23.929329]  ffffffffa00d1125 000000badb7bbda0 ffff880117dd8600 ffff8800db97a000
[   23.929330] Call Trace:
[   23.929336]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[   23.929355]  [<ffffffffa00d101a0>] ? insert_kthread_work+0x40/0x40
[   24.033302]  [<ffffffff8169623c>] ret_from_fork+0x7c/0xb0
[   24.033304]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   24.033306] XFS (vda1): Corruption detected. Unmount and run xfs_repair
[   24.033511] XFS (vda1): metadata I/O error: block 0x1212dd0 ("xfs_trans_read_buf_map") error 117 numblks 8
[   24.106127] ffff8800372a0000: 00 00 00 00 00 00 00 00 d2 f1 00 00 01 4d 00 92  .............M..
[   24.106128] ffff8800372a0010: 00 00 00 2e 00 00 00 02 00 00 17 2e 00 00 00 04  ................
[   24.106130] ffff8800372a0020: 14 10 19 e2 00 02 bc 02 14 10 19 e2 00 02 c2 a7  ................
[   24.106131] ffff8800372a0030: 14 10 19 e2 00 02 c5 d0 14 10 19 e2 00 02 c4 c8  ................
[   24.106134] XFS (vda1): Internal error __read_verify at line 186 of file fs/xfs/xfs_dir2_leaf.c.  Caller 0xffffffffa010c243
[   24.106137] CPU: 1 PID: 178 Comm: kworker/1:1H Not tainted 3.13.6-200.fc20.x86_64 #1
[   24.106138] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   24.106182] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[   24.106185]  0000000000000001 ffff8800db7bbd50 ffffffff8168730c ffff8800db97a000
[   24.106187]  ffff8800db7bbd68 ffffffffa00d10cb ffffffffa010c243 ffff8800db7bbda0
[   24.106189]  ffffffffa00d1125 000000badb7bbda0 ffff880117dd8780 ffff8800db97a000
[   24.106189] Call Trace:
[   24.106196]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[   24.106215]  [<ffffffffa00d10cb>] xfs_error_report+0x3b/0x40 [xfs]
[   24.106239]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.106257]  [<ffffffffa00d1125>] xfs_corruption_error+0x55/0x80 [xfs]
[   24.106280]  [<ffffffffa010c1b6>] __read_verify+0x76/0xf0 [xfs]
[   24.106303]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.106326]  [<ffffffffa010c243>] xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.106344]  [<ffffffffa00ce245>] xfs_buf_iodone_work+0x85/0xf0 [xfs]
[   24.106347]  [<ffffffff81087b76>] process_one_work+0x176/0x430
[   24.106349]  [<ffffffff810887ab>] worker_thread+0x11b/0x1H Not tainted 3.13.6-200.fc20.x86_64 #1
[   24.282672] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   24.282672] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[   24.282672]  0000000000000001 ffff8800db7bbd50 ffffffff8168730c ffff8800db97a000
[   24.282672]  ffff8800db7bbd68 ffffffffa00d10cb ffffffffa010c243 ffff8800db7bbda0
[   24.282672]  ffffffffa00d1125 000000badb7bbda0 ffff880117dd8780 ffff8800db97a000
[   24.282672] Call Trace:
[   24.282672]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[   24.282672]  [<ffffffffa00d10cb>] xfs_error_report+0x3b/0x40 [xfs]
[   24.282672]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.282672]  [<ffffffffa00d1125>] xfs_corruption_error+0x55/0x80 [xfs]
[   24.282672]  [<ffffffffa010c1b6>] __read_verify+0x76/0xf0 [xfs]
[   24.282672]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.282672]  [<ffffffffa010c243>] xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.282672]  [<ffffffffa00ce245>] xfs_buf_iodone_work+0x85/0xf0 [xfs]
[   24.282672]  [<ffffffff81087b76>] process_one_work+0x176/0x430
[   24.282672]  [<ffffffff810887ab>] worker_thread+0x11b/0x3a0
[   24.282672]  [<ffffffff81088690>] ? rescuer_thread+0x350/0x350
[   24.282672]  [<ffffffff8108f272>] kthread+0xd2/0xf0
[   24.282672]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   24.282672]  [<ffffffff8169623c>] ret_from_fork+0x7c/0xb0
[   24.282672]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   24.282672] XFS (vda1): Corruption detected. Unmount and run xfs_repair
[   24.296557] XFS (vda1): metadata I/O error: block 0x1212dd0 ("xfs_trans_read_buf_map") error 117 numblks 8
[   24.338934] ffff8800372a0000: 00 00 00 00 00 00 00 00 d2 f1 00 00 01 4d 00 92  .............M..
[   24.338935] ffff8800372a0010: 00 00 00 2e 00 00 00 02 00 00 17 2e 00 00 00 04  ................
[   24.338937] ffff8800372a0020: 14 10 19 e2 00 02 bc 02 14 10 19 e2 00 02 c2 a7  ................
[   24.338938] ffff8800372a0030: 14 10 19 e2 00 02 c5 d0 14 10 19 e2 00 02 c4 c8  ................
[   24.338941] XFS (vda1): Internal error __read_verify at line 186 of file fs/xfs/xfs_dir2_leaf.c.  Caller 0xffffffffa010c243
[   24.338945] CPU: 1 PID: 178 Comm: kworker/1:1H Not tainted 3.13.6-200.fc20.x86_64 #1
[   24.338945] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   24.338992] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[   24.338995]  0000000000000001 ffff8800db7bbd50 ffffffff8168730c ffff8800db97a000
[   24.338997]  ffff8800db7bbd68 ffffffffa00d10cb ffffffffa010c243 ffff8800db7bbda0
[   24.338999]  ffffffffa00d1125 000000badb7bbda0 ffff880117dd8780 ffff8800db97a000
[   24.339000] Call Trace:
[   24.339056]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[   24.339077]  [<ffffffffa00d10cb>] xfs_error_report+0x3b/0x40 [xfs]
[   24.339104]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.339124]  [<ffffffffa00d1125>] xfs_corruption_error+0x55/0x80 [xfs]
[   24.339150]  [<ffffffffa010c1b6>] __read_verify+0x76/0xf0 [xfs]
[   24.339176]  [<ffffffffa010c243>] ? xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.339202]  [<ffffffffa010c243>] xfs_dir3_leaf1_read_verify+0x13/0x20 [xfs]
[   24.339222]  [<ffffffffa00ce245>] xfs_buf_iodone_work+0x85/0xf0 [xfs]
[   24.339225]  [<ffffffff81087b76>] process_one_work+0x176/0x430
[   24.339227]  [<ffffffff810887ab>] worker_thread+0x11b/0x3a0
[   24.339229]  [<ffffffff81088690>] ? rescuer_thread+0x350/0x350
[   24.339232]  [<ffffffff8108f272>] kthread+0xd2/0xf0
[   24.339235]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   24.339238]  [<ffffffff8169623c>] ret_from_fork+0x7c/0xb0
[   24.339240]  [<ffffffff8108f1a0>] ? insert_kthread_work+0x40/0x40
[   24.339242] XFS (vda1): Corruption detected. Unmount and run xfs_repair
[   24.340307] XFS (vda1): metadata I/O error: block 0x1212dd0 ("xfs_trans_read_buf_map") error 117 numblks 8


Bye,

  Hannes

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 14:05       ` Hannes Frederic Sowa
@ 2014-03-27 15:15         ` Mark Tinguely
  2014-03-27 15:24           ` Hannes Frederic Sowa
  0 siblings, 1 reply; 16+ messages in thread
From: Mark Tinguely @ 2014-03-27 15:15 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: xfs

On 03/27/14 09:05, Hannes Frederic Sowa wrote:
> On Thu, Mar 27, 2014 at 08:34:14AM -0500, Mark Tinguely wrote:
>> On 03/27/14 08:23, Hannes Frederic Sowa wrote:
>>> On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
>>>> Have you tried to run a xfs_repair on the filesystem after the reboot?
>>>
>>> Yes, I did. I still use the filesystem and it works. As soon as I try to
>>> remove the directory again the same splash from above happens again.
>>
>> Is it the latest xfsprogs' repair?
>>
>> Do you have the output from the repair still?
>
> I can easily test this here, so you can throw any commands and tests at
> me. ;)
>
> This is the output:
>
> (I replayed the journal before that)
>
> pre-mount:/# xfs_repair -V
> xfs_repair version 3.1.11
> pre-mount:/# xfs_repair -v /dev/vda1
> Phase 1 - find and verify superblock...
>          - block cache size set to 372848 entries
> Phase 2 - using internal log
>          - zero log...
> zero_log: head block 5071 tail block 5071
>          - 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
> bad hash ordering in block 8388739 of directory inode 3543184

interesting. I will see if I can recreate it.

Are you open to making it an xfstest?

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 15:15         ` Mark Tinguely
@ 2014-03-27 15:24           ` Hannes Frederic Sowa
  2014-03-27 20:36             ` Mark Tinguely
  2014-03-27 20:57             ` Mark Tinguely
  0 siblings, 2 replies; 16+ messages in thread
From: Hannes Frederic Sowa @ 2014-03-27 15:24 UTC (permalink / raw)
  To: Mark Tinguely; +Cc: xfs

On Thu, Mar 27, 2014 at 10:15:01AM -0500, Mark Tinguely wrote:
> On 03/27/14 09:05, Hannes Frederic Sowa wrote:
> >On Thu, Mar 27, 2014 at 08:34:14AM -0500, Mark Tinguely wrote:
> >>On 03/27/14 08:23, Hannes Frederic Sowa wrote:
> >>>On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
> >>>>Have you tried to run a xfs_repair on the filesystem after the reboot?
> >>>
> >>>Yes, I did. I still use the filesystem and it works. As soon as I try to
> >>>remove the directory again the same splash from above happens again.
> >>
> >>Is it the latest xfsprogs' repair?
> >>
> >>Do you have the output from the repair still?
> >
> >I can easily test this here, so you can throw any commands and tests at
> >me. ;)
> >
> >This is the output:
> >
> >(I replayed the journal before that)
> >
> >pre-mount:/# xfs_repair -V
> >xfs_repair version 3.1.11
> >pre-mount:/# xfs_repair -v /dev/vda1
> >Phase 1 - find and verify superblock...
> >         - block cache size set to 372848 entries
> >Phase 2 - using internal log
> >         - zero log...
> >zero_log: head block 5071 tail block 5071
> >         - 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
> >bad hash ordering in block 8388739 of directory inode 3543184
> 
> interesting. I will see if I can recreate it.
> 
> Are you open to making it an xfstest?

Sure, I'll put it on my todo list for the weekend.

Thanks,

  Hannes

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 15:24           ` Hannes Frederic Sowa
@ 2014-03-27 20:36             ` Mark Tinguely
  2014-03-27 20:57             ` Mark Tinguely
  1 sibling, 0 replies; 16+ messages in thread
From: Mark Tinguely @ 2014-03-27 20:36 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: xfs

On 03/27/14 10:24, Hannes Frederic Sowa wrote:
> On Thu, Mar 27, 2014 at 10:15:01AM -0500, Mark Tinguely wrote:
>> On 03/27/14 09:05, Hannes Frederic Sowa wrote:
>>> On Thu, Mar 27, 2014 at 08:34:14AM -0500, Mark Tinguely wrote:
>>>> On 03/27/14 08:23, Hannes Frederic Sowa wrote:
>>>>> On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
>>>>>> Have you tried to run a xfs_repair on the filesystem after the reboot?
>>>>>
>>>>> Yes, I did. I still use the filesystem and it works. As soon as I try to
>>>>> remove the directory again the same splash from above happens again.
>>>>
>>>> Is it the latest xfsprogs' repair?
>>>>
>>>> Do you have the output from the repair still?
>>>
>>> I can easily test this here, so you can throw any commands and tests at
>>> me. ;)
>>>
>>> This is the output:
>>>
>>> (I replayed the journal before that)
>>>
>>> pre-mount:/# xfs_repair -V
>>> xfs_repair version 3.1.11
>>> pre-mount:/# xfs_repair -v /dev/vda1
>>> Phase 1 - find and verify superblock...
>>>          - block cache size set to 372848 entries
>>> Phase 2 - using internal log
>>>          - zero log...
>>> zero_log: head block 5071 tail block 5071
>>>          - 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
>>> bad hash ordering in block 8388739 of directory inode 3543184
>>
>> interesting. I will see if I can recreate it.
>>
>> Are you open to making it an xfstest?
>
> Sure, I'll put it on my todo list for the weekend.
>
> Thanks,
>
>    Hannes


I will bisect where this started to happen. It appears to be around 
Linux 3.10.

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 15:24           ` Hannes Frederic Sowa
  2014-03-27 20:36             ` Mark Tinguely
@ 2014-03-27 20:57             ` Mark Tinguely
  2014-03-27 21:15               ` Hannes Frederic Sowa
  1 sibling, 1 reply; 16+ messages in thread
From: Mark Tinguely @ 2014-03-27 20:57 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: xfs

On 03/27/14 10:24, Hannes Frederic Sowa wrote:
> On Thu, Mar 27, 2014 at 10:15:01AM -0500, Mark Tinguely wrote:
>> On 03/27/14 09:05, Hannes Frederic Sowa wrote:
>>> On Thu, Mar 27, 2014 at 08:34:14AM -0500, Mark Tinguely wrote:
>>>> On 03/27/14 08:23, Hannes Frederic Sowa wrote:
>>>>> On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
>>>>>> Have you tried to run a xfs_repair on the filesystem after the reboot?
>>>>>
>>>>> Yes, I did. I still use the filesystem and it works. As soon as I try to
>>>>> remove the directory again the same splash from above happens again.
>>>>
>>>> Is it the latest xfsprogs' repair?
>>>>
>>>> Do you have the output from the repair still?
>>>
>>> I can easily test this here, so you can throw any commands and tests at
>>> me. ;)
>>>
>>> This is the output:
>>>
>>> (I replayed the journal before that)
>>>
>>> pre-mount:/# xfs_repair -V
>>> xfs_repair version 3.1.11
>>> pre-mount:/# xfs_repair -v /dev/vda1
>>> Phase 1 - find and verify superblock...
>>>          - block cache size set to 372848 entries
>>> Phase 2 - using internal log
>>>          - zero log...
>>> zero_log: head block 5071 tail block 5071
>>>          - 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
>>> bad hash ordering in block 8388739 of directory inode 3543184
>>
>> interesting. I will see if I can recreate it.
>>
>> Are you open to making it an xfstest?
>
> Sure, I'll put it on my todo list for the weekend.
>
> Thanks,
>
>    Hannes

I will bisect to find the introduction. It appears be somewhere between 
Linux 3.9 and 3.10.

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 20:57             ` Mark Tinguely
@ 2014-03-27 21:15               ` Hannes Frederic Sowa
  2014-03-27 21:20                 ` Mark Tinguely
  0 siblings, 1 reply; 16+ messages in thread
From: Hannes Frederic Sowa @ 2014-03-27 21:15 UTC (permalink / raw)
  To: Mark Tinguely; +Cc: xfs

On Thu, Mar 27, 2014 at 03:57:45PM -0500, Mark Tinguely wrote:
> On 03/27/14 10:24, Hannes Frederic Sowa wrote:
> >On Thu, Mar 27, 2014 at 10:15:01AM -0500, Mark Tinguely wrote:
> >>On 03/27/14 09:05, Hannes Frederic Sowa wrote:
> >>>On Thu, Mar 27, 2014 at 08:34:14AM -0500, Mark Tinguely wrote:
> >>>>On 03/27/14 08:23, Hannes Frederic Sowa wrote:
> >>>>>On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
> >>>>>>Have you tried to run a xfs_repair on the filesystem after the reboot?
> >>>>>
> >>>>>Yes, I did. I still use the filesystem and it works. As soon as I try 
> >>>>>to
> >>>>>remove the directory again the same splash from above happens again.
> >>>>
> >>>>Is it the latest xfsprogs' repair?
> >>>>
> >>>>Do you have the output from the repair still?
> >>>
> >>>I can easily test this here, so you can throw any commands and tests at
> >>>me. ;)
> >>>
> >>>This is the output:
> >>>
> >>>(I replayed the journal before that)
> >>>
> >>>pre-mount:/# xfs_repair -V
> >>>xfs_repair version 3.1.11
> >>>pre-mount:/# xfs_repair -v /dev/vda1
> >>>Phase 1 - find and verify superblock...
> >>>         - block cache size set to 372848 entries
> >>>Phase 2 - using internal log
> >>>         - zero log...
> >>>zero_log: head block 5071 tail block 5071
> >>>         - 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
> >>>bad hash ordering in block 8388739 of directory inode 3543184
> >>
> >>interesting. I will see if I can recreate it.
> >>
> >>Are you open to making it an xfstest?
> >
> >Sure, I'll put it on my todo list for the weekend.
> >
> I will bisect to find the introduction. It appears be somewhere between 
> Linux 3.9 and 3.10.

Thanks!

Maybe it would be best to add a seed to the hashing function (and the super
block)?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: xfs errors while unlinking filenames with hash collisions
  2014-03-27 21:15               ` Hannes Frederic Sowa
@ 2014-03-27 21:20                 ` Mark Tinguely
  0 siblings, 0 replies; 16+ messages in thread
From: Mark Tinguely @ 2014-03-27 21:20 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: xfs

On 03/27/14 16:15, Hannes Frederic Sowa wrote:
> On Thu, Mar 27, 2014 at 03:57:45PM -0500, Mark Tinguely wrote:
>> On 03/27/14 10:24, Hannes Frederic Sowa wrote:
>>> On Thu, Mar 27, 2014 at 10:15:01AM -0500, Mark Tinguely wrote:
>>>> On 03/27/14 09:05, Hannes Frederic Sowa wrote:
>>>>> On Thu, Mar 27, 2014 at 08:34:14AM -0500, Mark Tinguely wrote:
>>>>>> On 03/27/14 08:23, Hannes Frederic Sowa wrote:
>>>>>>> On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
>>>>>>>> Have you tried to run a xfs_repair on the filesystem after the reboot?
>>>>>>>
>>>>>>> Yes, I did. I still use the filesystem and it works. As soon as I try
>>>>>>> to
>>>>>>> remove the directory again the same splash from above happens again.
>>>>>>
>>>>>> Is it the latest xfsprogs' repair?
>>>>>>
>>>>>> Do you have the output from the repair still?
>>>>>
>>>>> I can easily test this here, so you can throw any commands and tests at
>>>>> me. ;)
>>>>>
>>>>> This is the output:
>>>>>
>>>>> (I replayed the journal before that)
>>>>>
>>>>> pre-mount:/# xfs_repair -V
>>>>> xfs_repair version 3.1.11
>>>>> pre-mount:/# xfs_repair -v /dev/vda1
>>>>> Phase 1 - find and verify superblock...
>>>>>          - block cache size set to 372848 entries
>>>>> Phase 2 - using internal log
>>>>>          - zero log...
>>>>> zero_log: head block 5071 tail block 5071
>>>>>          - 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
>>>>> bad hash ordering in block 8388739 of directory inode 3543184
>>>>
>>>> interesting. I will see if I can recreate it.
>>>>
>>>> Are you open to making it an xfstest?
>>>
>>> Sure, I'll put it on my todo list for the weekend.
>>>
>> I will bisect to find the introduction. It appears be somewhere between
>> Linux 3.9 and 3.10.
>
> Thanks!
>
> Maybe it would be best to add a seed to the hashing function (and the super
> block)?
>

Good idea - replicate a test like fsstress.

I bet you could narrow down the iterations required to cause the hang.
I have been using wall clock and disk blocks used as a guide so far.

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH xfstests] tests for file hash collisions on xfs filesystems
  2014-03-27  7:41 xfs errors while unlinking filenames with hash collisions Hannes Frederic Sowa
  2014-03-27 13:14 ` Mark Tinguely
@ 2014-04-01 18:49 ` Hannes Frederic Sowa
  2014-04-01 18:56   ` Mark Tinguely
  2014-04-01 23:03   ` [PATCH v2 xfstests] add tests for unlinking directories with hash collisions Hannes Frederic Sowa
  1 sibling, 2 replies; 16+ messages in thread
From: Hannes Frederic Sowa @ 2014-04-01 18:49 UTC (permalink / raw)
  To: xfs

This patch adds a new check for xfstests, which generates directories with 64
distinct hash values and afterwards tries to delete the directory. This caused
a hash ordering issue.

The file-hash-tool can also generate files (this should result in the same
original problem as with directories) and generate only filenames with one
hash (this can be very well optimized in future).

This is just a preview. Dave Chiner seems to want this as soon as possible,
thus please review and suggest changes so I can adapt this patch ASAP.

Thanks!

Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
 .gitignore           |   1 +
 ltp/Makefile         |   2 +-
 ltp/file-hash-test.c | 189 +++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/xfs/307        |  61 +++++++++++++++++
 tests/xfs/307.out    |   2 +
 tests/xfs/group      |   1 +
 6 files changed, 255 insertions(+), 1 deletion(-)
 create mode 100644 ltp/file-hash-test.c
 create mode 100755 tests/xfs/307
 create mode 100644 tests/xfs/307.out

diff --git a/.gitignore b/.gitignore
index b6f2463..c023afc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -26,6 +26,7 @@
 /ltp/fsstress
 /ltp/fsx
 /ltp/growfiles
+/ltp/file-hash-test
 /ltp/iogen
 
 # src/ binaries
diff --git a/ltp/Makefile b/ltp/Makefile
index 5bea492..c1ec489 100644
--- a/ltp/Makefile
+++ b/ltp/Makefile
@@ -5,7 +5,7 @@
 TOPDIR = ..
 include $(TOPDIR)/include/builddefs
 
-TARGETS = doio fsstress fsx growfiles iogen
+TARGETS = doio fsstress fsx growfiles iogen file-hash-test
 SCRIPTS = rwtest.sh
 CFILES = $(TARGETS:=.c)
 HFILES = doio.h
diff --git a/ltp/file-hash-test.c b/ltp/file-hash-test.c
new file mode 100644
index 0000000..c297034
--- /dev/null
+++ b/ltp/file-hash-test.c
@@ -0,0 +1,189 @@
+/*
+ * creates files or directories with similar hashes
+ *
+ * If used without option 64 different hash values are possible If
+ * '-s' is specified as command line option, it does reduce the number
+ * of hashes to just one.
+ *
+ * '-f' creates files - this is the default
+ * '-d' creates directories
+ * '-n 200000' specified the number of file names to generate
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <string.h>
+
+#include <sys/stat.h>
+#include <sys/time.h>
+#include <unistd.h>
+#include <errno.h>
+#include <fcntl.h>
+
+static enum {
+	DIRECTORY,
+	FILENAME,
+} touch_mode = FILENAME;
+
+static bool one_hash = false;
+
+static uint32_t rol32(uint32_t word, unsigned int shift)
+{
+	return (word << shift) | (word >> (32 - shift));
+}
+
+static uint32_t xfs_hash(const uint8_t *name, int namelen)
+{
+	uint32_t hash;
+
+	for (hash = 0; namelen >= 4; namelen -= 4, name += 4)
+		hash = (name[0] << 21) ^ (name[1] << 14) ^ (name[2] << 7) ^
+		       (name[3] << 0) ^ rol32(hash, 7 * 4);
+
+	if (namelen) {
+		fprintf(stderr,
+			"internal error: "
+			"misbalanced input buffer to xfs_hash - "
+			"overlapping %d bytes\n", namelen);
+		exit(1);
+	}
+
+	return hash;
+}
+
+static uint8_t gen_rand(void)
+{
+	uint8_t r;
+	while (!(r = rand()));
+	return r;
+}
+
+static uint8_t buffer[252+1] = {0};
+
+static void gen_name(void)
+{
+	int idx;
+	uint32_t hash, last;
+
+again:
+	for (idx = 0; idx < 252-4; idx+=4) {
+		buffer[idx + 0] = gen_rand();
+		buffer[idx + 1] = gen_rand();
+		buffer[idx + 2] = gen_rand();
+		buffer[idx + 3] = gen_rand();
+	}
+
+	hash = rol32(xfs_hash(buffer, 248), 7 * 4);
+	last = hash ^ ~0U;
+
+	if (last == 0)
+		goto again;
+
+	buffer[idx + 0] = (last >> 21) & 0xff;
+	buffer[idx + 1] = (last >> 14) & 0xff;
+	buffer[idx + 2] = (last >> 7)  & 0xff;
+	buffer[idx + 3] = last & 0xff;
+
+	if (memchr(buffer, '.', sizeof(buffer)) ||
+	    memchr(buffer, '/', sizeof(buffer)))
+		goto again;
+
+	if (one_hash) {
+		/* very poor - can be improved later */
+		static bool done = false;
+		static uint32_t filter;
+
+		if (!done) {
+			filter = xfs_hash(buffer, 252);
+			done = true;
+			return;
+		}
+
+		if (filter != xfs_hash(buffer, 252))
+			goto again;
+	}
+}
+
+static int touch(const char *buffer)
+{
+	if (touch_mode == DIRECTORY) {
+		if (mkdir(buffer, S_IRWXU)) {
+			/* ignore if directory is already present */
+			if (errno == EEXIST)
+				return 0;
+			perror("mkdir with random directory name");
+			return 1;
+		}
+	} else if (touch_mode == FILENAME) {
+		int fd = creat(buffer, S_IRWXU);
+		if (fd == -1) {
+			/* ignore duplicate files */
+			if (errno == EEXIST)
+				return 0;
+			perror("creat with random directory name");
+			return 1;
+		}
+		if (close(fd)) {
+			perror("close is leaking a file descriptor");
+			return 1;
+		}
+		return 0;
+	}
+	return 0;
+}
+
+static void do_seed(void)
+{
+	struct timeval tv;
+	if (gettimeofday(&tv, NULL)) {
+		perror("gettimeofday");
+		exit(1);
+	}
+	srand(tv.tv_sec ^ tv.tv_usec ^ getpid());
+}
+
+int main(int argc, char **argv)
+{
+	const char allopts[] = "vsdfn:";
+	int c, orig_cycles, errors = 0, cycles = 200000;
+
+	while ((c = getopt(argc, argv, allopts)) != -1) {
+		switch (c) {
+		case 'd':
+			touch_mode = DIRECTORY;
+			break;
+		case 'f':
+			touch_mode = FILENAME;
+			break;
+		case 'n':
+			errno = 0;
+			if (sscanf(optarg, "%d", &cycles) != 1 ||
+			    errno == ERANGE) {
+				fputs("could not parse number of iterations", stderr);
+				exit(1);
+			}
+			break;
+		case 's':
+			one_hash = true;
+			break;
+		}
+	}
+
+	orig_cycles = cycles;
+
+	do_seed();
+
+	while (cycles--) {
+		gen_name();
+		errors += touch((char *)buffer);
+	}
+
+	if (errors)
+		fprintf(stderr, "creating %d %s caused %d errors\n",
+			orig_cycles, touch_mode == FILENAME ? "files" : "directories",
+			errors);
+
+	return 0;
+}
diff --git a/tests/xfs/307 b/tests/xfs/307
new file mode 100755
index 0000000..12a322a
--- /dev/null
+++ b/tests/xfs/307
@@ -0,0 +1,61 @@
+#! /bin/bash
+# FS QA Test No. 001
+#
+# what am I here for?
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2014 YOUR NAME HERE.  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
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+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
+
+# real QA test starts here
+
+# Modify as appropriate.
+_supported_fs generic
+_supported_os IRIX Linux
+
+mkdir $TEST_DIR/x
+cd $TEST_DIR/x
+
+$here/ltp/file-hash-test -d -n 200000
+cd $here
+# kernel should oops here
+rm -rf $TEST_DIR/x
+
+echo "If we got here, everything seems fine at first."
+
+# success, all done
+status=0
+exit
diff --git a/tests/xfs/307.out b/tests/xfs/307.out
new file mode 100644
index 0000000..6cd3cd6
--- /dev/null
+++ b/tests/xfs/307.out
@@ -0,0 +1,2 @@
+QA output created by 307
+If we got here, everything seems fine at first.
diff --git a/tests/xfs/group b/tests/xfs/group
index ba34650..b5695d3 100644
--- a/tests/xfs/group
+++ b/tests/xfs/group
@@ -189,3 +189,4 @@
 304 auto quick quota
 305 auto quota
 306 auto stress log metadata repair
+307 auto stress
-- 
1.9.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH xfstests] tests for file hash collisions on xfs filesystems
  2014-04-01 18:49 ` [PATCH xfstests] tests for file hash collisions on xfs filesystems Hannes Frederic Sowa
@ 2014-04-01 18:56   ` Mark Tinguely
  2014-04-01 23:03   ` [PATCH v2 xfstests] add tests for unlinking directories with hash collisions Hannes Frederic Sowa
  1 sibling, 0 replies; 16+ messages in thread
From: Mark Tinguely @ 2014-04-01 18:56 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: xfs

On 04/01/14 13:49, Hannes Frederic Sowa wrote:
> This patch adds a new check for xfstests, which generates directories with 64
> distinct hash values and afterwards tries to delete the directory. This caused
> a hash ordering issue.
>
> The file-hash-tool can also generate files (this should result in the same
> original problem as with directories) and generate only filenames with one
> hash (this can be very well optimized in future).
>
> This is just a preview. Dave Chiner seems to want this as soon as possible,
> thus please review and suggest changes so I can adapt this patch ASAP.
>
> Thanks!
>
> Signed-off-by: Hannes Frederic Sowa<hannes@stressinduktion.org>
> ---

I had some suggestions for the C and xfstests that cross paths with this 
post.

--Mark.


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH v2 xfstests] add tests for unlinking directories with hash collisions
  2014-04-01 18:49 ` [PATCH xfstests] tests for file hash collisions on xfs filesystems Hannes Frederic Sowa
  2014-04-01 18:56   ` Mark Tinguely
@ 2014-04-01 23:03   ` Hannes Frederic Sowa
  2014-04-02 12:34     ` [PATCH v3 " Hannes Frederic Sowa
  1 sibling, 1 reply; 16+ messages in thread
From: Hannes Frederic Sowa @ 2014-04-01 23:03 UTC (permalink / raw)
  To: xfs; +Cc: tinguely

Mark Tinguely says:
This tests use the XFS hash routine to create several directories
that all have the same small (64) group of hashes. Commit f5ea110
("xfs: add CRCs to dir2/da node) added a hash ordering regression
and this test make sure the directory name hash order is preserved.

Sample backtrace this test tries to prevent in future:

[ 3856.245843] XFS (vda1): Internal error xfs_trans_cancel at line 966 of file fs/xfs/xfs_trans.c.  Caller 0xffffffffa01186bc
[ 3856.249049] CPU: 1 PID: 866 Comm: rm Not tainted 3.13.6-200.fc20.x86_64 #1
[ 3856.250966] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 3856.252615]  000000000000000c ffff8800d23a7d68 ffffffff8168730c ffff8800cf5462b8
[ 3856.254823]  ffff8800d23a7d80 ffffffffa00d00cb ffffffffa01186bc ffff8800d23a7da8
[ 3856.257241]  ffffffffa00e5459 ffff8800d9ac3400 ffff8800d23a7e30 ffff8800371b6800
[ 3856.259420] Call Trace:
[ 3856.260172]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[ 3856.261717]  [<ffffffffa00d00cb>] xfs_error_report+0x3b/0x40 [xfs]
[ 3856.263472]  [<ffffffffa01186bc>] ? xfs_remove+0x1ac/0x370 [xfs]
[ 3856.270838]  [<ffffffffa00e5459>] xfs_trans_cancel+0xd9/0x100 [xfs]
[ 3856.272783]  [<ffffffffa01186bc>] xfs_remove+0x1ac/0x370 [xfs]
[ 3856.274531]  [<ffffffffa00db40b>] xfs_vn_unlink+0x4b/0x90 [xfs]
[ 3856.276286]  [<ffffffff811c61b8>] vfs_rmdir+0xa8/0x100
[ 3856.277821]  [<ffffffff811c638d>] do_rmdir+0x17d/0x1d0
[ 3856.281021]  [<ffffffff811ba7fe>] ? ____fput+0xe/0x10
[ 3856.285261]  [<ffffffff8108c11c>] ? task_work_run+0xac/0xe0
[ 3856.286952]  [<ffffffff81013a31>] ? do_notify_resume+0x61/0xa0
[ 3856.288693]  [<ffffffff811c9a65>] SyS_unlinkat+0x25/0x40
[ 3856.290407]  [<ffffffff816962e9>] system_call_fastpath+0x16/0x1b
[ 3856.292685] XFS (vda1): xfs_do_force_shutdown(0x8) called from line 967 of file fs/xfs/xfs_trans.c.  Return address = 0xffffffffa00e5472
[ 3856.627330] XFS (vda1): Corruption of in-memory data detected.  Shutting down filesystem
[ 3856.627332] XFS (vda1): Please umount the filesystem and rectify the problem(s)

With help from Mark Tinguely, thanks very much!

Cc: Dave Chinner <david@fromorbit.com>
Cc: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
 .gitignore                    |   1 +
 src/Makefile                  |   2 +-
 src/generate-hash-collision.c | 223 ++++++++++++++++++++++++++++++++++++++++++
 tests/xfs/307                 |  63 ++++++++++++
 tests/xfs/307.out             |  28 ++++++
 tests/xfs/group               |   1 +
 6 files changed, 317 insertions(+), 1 deletion(-)
 create mode 100644 src/generate-hash-collision.c
 create mode 100755 tests/xfs/307
 create mode 100644 tests/xfs/307.out

diff --git a/.gitignore b/.gitignore
index b6f2463..049f2e0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -50,6 +50,7 @@
 /src/fsync-tester
 /src/ftrunc
 /src/genhashnames
+/src/generate-hash-collision
 /src/getdevicesize
 /src/getpagesize
 /src/godown
diff --git a/src/Makefile b/src/Makefile
index 6509f2d..1e9ec61 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -11,7 +11,7 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
 	devzero feature alloc fault fstest t_access_root \
 	godown resvtest writemod makeextents itrash rename \
 	multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
-	t_mmap_writev t_truncate_cmtime
+	t_mmap_writev t_truncate_cmtime generate-hash-collision
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
 	preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/generate-hash-collision.c b/src/generate-hash-collision.c
new file mode 100644
index 0000000..76c7b3e
--- /dev/null
+++ b/src/generate-hash-collision.c
@@ -0,0 +1,223 @@
+/*
+ * Generates files or directories with hash collisions on a XFS filesystem
+ * Copyright (C) 2014 Hannes Frederic Sowa
+ *
+ * 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 will 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 to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <string.h>
+
+#include <sys/stat.h>
+#include <sys/time.h>
+#include <unistd.h>
+#include <errno.h>
+#include <fcntl.h>
+
+static enum {
+	ILLEGAL,
+	DIRECTORY,
+	FILENAME,
+} touch_mode = ILLEGAL;
+
+static bool one_hash = false;
+
+static uint32_t rol32(uint32_t word, unsigned int shift)
+{
+	return (word << shift) | (word >> (32 - shift));
+}
+
+static uint32_t xfs_da_hashname(const uint8_t *name, int namelen)
+{
+	uint32_t hash;
+
+	for (hash = 0; namelen >= 4; namelen -= 4, name += 4)
+		hash = (name[0] << 21) ^ (name[1] << 14) ^ (name[2] << 7) ^
+		       (name[3] << 0) ^ rol32(hash, 7 * 4);
+
+	if (namelen) {
+		fprintf(stderr,
+			"internal error: "
+			"misbalanced input buffer to xfs_da_hashname - "
+			"overlapping %d bytes\n", namelen);
+		exit(1);
+	}
+
+	return hash;
+}
+
+static uint8_t gen_rand(void)
+{
+	uint8_t r;
+	while (!(r = rand()));
+	return r;
+}
+
+static uint8_t buffer[252+1] = {0};
+
+static void gen_name(void)
+{
+	int idx;
+	uint32_t hash, last;
+
+again:
+	for (idx = 0; idx < 252-4; idx+=4) {
+		buffer[idx + 0] = gen_rand();
+		buffer[idx + 1] = gen_rand();
+		buffer[idx + 2] = gen_rand();
+		buffer[idx + 3] = gen_rand();
+	}
+
+	hash = rol32(xfs_da_hashname(buffer, 248), 7 * 4);
+	last = hash ^ ~0U;
+
+	if (last == 0)
+		goto again;
+
+	buffer[idx + 0] = (last >> 21) & 0xff;
+	buffer[idx + 1] = (last >> 14) & 0xff;
+	buffer[idx + 2] = (last >> 7)  & 0xff;
+	buffer[idx + 3] = last & 0xff;
+
+	if (memchr(buffer, '.', sizeof(buffer)) ||
+	    memchr(buffer, '/', sizeof(buffer)))
+		goto again;
+
+	if (one_hash) {
+		/* very poor - can be improved later */
+		static bool done = false;
+		static uint32_t filter;
+
+		if (!done) {
+			filter = xfs_da_hashname(buffer, 252);
+			done = true;
+			return;
+		}
+
+		if (filter != xfs_da_hashname(buffer, 252))
+			goto again;
+	}
+}
+
+static int touch(const char *buffer)
+{
+	if (touch_mode == DIRECTORY) {
+		if (mkdir(buffer, S_IRWXU)) {
+			/* ignore if directory is already present */
+			if (errno == EEXIST)
+				return 0;
+			perror("mkdir with random directory name");
+			return 1;
+		}
+	} else if (touch_mode == FILENAME) {
+		int fd = creat(buffer, S_IRWXU);
+		if (fd == -1) {
+			/* ignore duplicate files */
+			if (errno == EEXIST)
+				return 0;
+			perror("creat with random directory name");
+			return 1;
+		}
+		if (close(fd)) {
+			perror("close is leaking a file descriptor");
+			return 1;
+		}
+		return 0;
+	}
+	return 0;
+}
+
+static void do_seed(void)
+{
+	struct timeval tv;
+	if (gettimeofday(&tv, NULL)) {
+		perror("gettimeofday");
+		exit(1);
+	}
+	srand(tv.tv_sec ^ tv.tv_usec ^ getpid());
+}
+
+static void usage_and_exit(const char *pname)
+{
+	fprintf(stderr, "usage: %s [-d] [-f] [-n num] [-s] directory\n"
+		        "\t-f\tcreate files (the default)\n"
+			"\t-d\tcreate directories\n"
+			"\t-n num\tcreate num directories or files (default 200000)\n"
+			"\t-s\tonly generate one hash\n"
+			"\tdirectory\tthe directory to chdir() to\n",
+		pname);
+	exit(1);
+}
+
+int main(int argc, char **argv)
+{
+	const char allopts[] = "hsdfn:";
+	int c, orig_cycles, errors = 0, cycles = 200000;
+
+	while ((c = getopt(argc, argv, allopts)) != -1) {
+		switch (c) {
+		case 'd':
+			if (touch_mode != ILLEGAL)
+				usage_and_exit(argv[0]);
+			touch_mode = DIRECTORY;
+			break;
+		case 'f':
+			if (touch_mode != ILLEGAL)
+				usage_and_exit(argv[0]);
+			touch_mode = FILENAME;
+			break;
+		case 'n':
+			errno = 0;
+			if (sscanf(optarg, "%d", &cycles) != 1 ||
+			    errno == ERANGE) {
+				fputs("could not parse number of iterations", stderr);
+				exit(1);
+			}
+			break;
+		case 's':
+			one_hash = true;
+			break;
+		default:
+			usage_and_exit(argv[0]);
+			break;
+		}
+	}
+
+	if (argc <= optind || touch_mode == ILLEGAL)
+		usage_and_exit(argv[0]);
+
+	if (chdir(argv[optind])) {
+		perror("chdir");
+		exit(1);
+	}
+
+	orig_cycles = cycles;
+
+	do_seed();
+
+	while (cycles--) {
+		gen_name();
+		errors += touch((char *)buffer);
+	}
+
+	if (errors)
+		fprintf(stderr, "creating %d %s caused %d errors\n",
+			orig_cycles, touch_mode == FILENAME ? "files" : "directories",
+			errors);
+
+	return 0;
+}
diff --git a/tests/xfs/307 b/tests/xfs/307
new file mode 100755
index 0000000..b31cc13
--- /dev/null
+++ b/tests/xfs/307
@@ -0,0 +1,63 @@
+#! /bin/bash
+# FS QA Test No. 307
+#
+# Test that directory hash entries are place in the correct order.
+# commit f5ea110 ("xfs: add CRCs to dir2/da node blocks") left the
+# directory with incorrect hash ordering.
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2014 Hannes Frederic Sowa.  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
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+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
+. ./common/repair
+
+# real QA test starts here
+
+_supported_fs xfs
+_supported_os Linux
+_require_scratch
+
+_scratch_mkfs_xfs | _filter_mkfs 2>$tmp.mkfs
+_scratch_mount | _filter_scratch
+
+mkdir $SCRATCH_MNT/x
+$here/src/generate-hash-collision -d -n 200000 $SCRATCH_MNT/x
+umount $SCRATCH_MNT 2>&1 | _filter_scratch
+
+_scratch_xfs_repair 2>&1 | _filter_repair
+
+# success, all done
+status=0
+exit
diff --git a/tests/xfs/307.out b/tests/xfs/307.out
new file mode 100644
index 0000000..eaf5716
--- /dev/null
+++ b/tests/xfs/307.out
@@ -0,0 +1,28 @@
+QA output created by 307
+meta-data=DDEV isize=XXX agcount=N, agsize=XXX blks
+data     = bsize=XXX blocks=XXX, imaxpct=PCT
+         = sunit=XXX swidth=XXX, unwritten=X
+naming   =VERN bsize=XXX
+log      =LDEV bsize=XXX blocks=XXX
+realtime =RDEV extsz=XXX blocks=XXX, rtextents=XXX
+Phase 1 - find and verify superblock...
+Phase 2 - using <TYPEOF> log
+        - 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...
+        - process newly discovered inodes...
+Phase 4 - check for duplicate blocks...
+        - setting up duplicate extent list...
+        - check for inodes claiming duplicate blocks...
+Phase 5 - rebuild AG headers and trees...
+        - reset superblock...
+Phase 6 - check inode connectivity...
+        - resetting contents of realtime bitmap and summary inodes
+        - traversing filesystem ...
+        - traversal finished ...
+        - moving disconnected inodes to lost+found ...
+Phase 7 - verify and correct link counts...
+done
diff --git a/tests/xfs/group b/tests/xfs/group
index ba34650..a1ef7f9 100644
--- a/tests/xfs/group
+++ b/tests/xfs/group
@@ -189,3 +189,4 @@
 304 auto quick quota
 305 auto quota
 306 auto stress log metadata repair
+307 auto dir
-- 
1.9.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v3 xfstests] add tests for unlinking directories with hash collisions
  2014-04-01 23:03   ` [PATCH v2 xfstests] add tests for unlinking directories with hash collisions Hannes Frederic Sowa
@ 2014-04-02 12:34     ` Hannes Frederic Sowa
  2014-04-02 13:07       ` Mark Tinguely
  0 siblings, 1 reply; 16+ messages in thread
From: Hannes Frederic Sowa @ 2014-04-02 12:34 UTC (permalink / raw)
  To: xfs; +Cc: tinguely

This tests creates several directories that have the same small (8)
group of hashes to ensure the hash ordering of file and directories
are preserved.

Sample backtrace this test tries to prevent in future:

[ 3856.245843] XFS (vda1): Internal error xfs_trans_cancel at line 966 of file fs/xfs/xfs_trans.c.  Caller 0xffffffffa01186bc
[ 3856.249049] CPU: 1 PID: 866 Comm: rm Not tainted 3.13.6-200.fc20.x86_64 #1
[ 3856.250966] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 3856.252615]  000000000000000c ffff8800d23a7d68 ffffffff8168730c ffff8800cf5462b8
[ 3856.254823]  ffff8800d23a7d80 ffffffffa00d00cb ffffffffa01186bc ffff8800d23a7da8
[ 3856.257241]  ffffffffa00e5459 ffff8800d9ac3400 ffff8800d23a7e30 ffff8800371b6800
[ 3856.259420] Call Trace:
[ 3856.260172]  [<ffffffff8168730c>] dump_stack+0x45/0x56
[ 3856.261717]  [<ffffffffa00d00cb>] xfs_error_report+0x3b/0x40 [xfs]
[ 3856.263472]  [<ffffffffa01186bc>] ? xfs_remove+0x1ac/0x370 [xfs]
[ 3856.270838]  [<ffffffffa00e5459>] xfs_trans_cancel+0xd9/0x100 [xfs]
[ 3856.272783]  [<ffffffffa01186bc>] xfs_remove+0x1ac/0x370 [xfs]
[ 3856.274531]  [<ffffffffa00db40b>] xfs_vn_unlink+0x4b/0x90 [xfs]
[ 3856.276286]  [<ffffffff811c61b8>] vfs_rmdir+0xa8/0x100
[ 3856.277821]  [<ffffffff811c638d>] do_rmdir+0x17d/0x1d0
[ 3856.281021]  [<ffffffff811ba7fe>] ? ____fput+0xe/0x10
[ 3856.285261]  [<ffffffff8108c11c>] ? task_work_run+0xac/0xe0
[ 3856.286952]  [<ffffffff81013a31>] ? do_notify_resume+0x61/0xa0
[ 3856.288693]  [<ffffffff811c9a65>] SyS_unlinkat+0x25/0x40
[ 3856.290407]  [<ffffffff816962e9>] system_call_fastpath+0x16/0x1b
[ 3856.292685] XFS (vda1): xfs_do_force_shutdown(0x8) called from line 967 of file fs/xfs/xfs_trans.c.  Return address = 0xffffffffa00e5472
[ 3856.627330] XFS (vda1): Corruption of in-memory data detected.  Shutting down filesystem
[ 3856.627332] XFS (vda1): Please umount the filesystem and rectify the problem(s)

With help from Mark Tinguely, thanks very much!

Cc: Dave Chinner <david@fromorbit.com>
Cc: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
Changelog:

v2)
* first serious proposal

v3)
* reduced number of possible generated hashes to 8 and thus lowered the number of
  generated files to 10_000 which still generate the corruption in all of my
  10 tests. This speeds up the test considerable. Maybe we can add
  quick to the group description now?
* updated changelog

Also:
When testing this program with reduced number of generated hashes and
huge amount of test files, xfs_repair needs a considerable amount of
time to check the directory (I aborted it). I guess this is because the
hash tables get flattened to linked lists.

I don't know if there are other runtime explosions in other parts of
the code (maybe in the kernel).  I suggest to add a random perturbation
to the hash function, which unluckily seems to be included into the
superblock then, too.

Please have a look!

Thanks,

  Hannes

 .gitignore                    |   1 +
 src/Makefile                  |   2 +-
 src/generate-hash-collision.c | 223 ++++++++++++++++++++++++++++++++++++++++++
 tests/xfs/307                 |  63 ++++++++++++
 tests/xfs/307.out             |  28 ++++++
 tests/xfs/group               |   1 +
 6 files changed, 317 insertions(+), 1 deletion(-)
 create mode 100644 src/generate-hash-collision.c
 create mode 100755 tests/xfs/307
 create mode 100644 tests/xfs/307.out

diff --git a/.gitignore b/.gitignore
index b6f2463..049f2e0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -50,6 +50,7 @@
 /src/fsync-tester
 /src/ftrunc
 /src/genhashnames
+/src/generate-hash-collision
 /src/getdevicesize
 /src/getpagesize
 /src/godown
diff --git a/src/Makefile b/src/Makefile
index 6509f2d..1e9ec61 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -11,7 +11,7 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
 	devzero feature alloc fault fstest t_access_root \
 	godown resvtest writemod makeextents itrash rename \
 	multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
-	t_mmap_writev t_truncate_cmtime
+	t_mmap_writev t_truncate_cmtime generate-hash-collision
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
 	preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/generate-hash-collision.c b/src/generate-hash-collision.c
new file mode 100644
index 0000000..55cec87
--- /dev/null
+++ b/src/generate-hash-collision.c
@@ -0,0 +1,223 @@
+/*
+ * Generates files or directories with hash collisions on a XFS filesystem
+ * Copyright (C) 2014 Hannes Frederic Sowa
+ *
+ * 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 will 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 to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <string.h>
+
+#include <sys/stat.h>
+#include <sys/time.h>
+#include <unistd.h>
+#include <errno.h>
+#include <fcntl.h>
+
+static enum {
+	ILLEGAL,
+	DIRECTORY,
+	FILENAME,
+} touch_mode = ILLEGAL;
+
+static bool one_hash = false;
+
+static uint32_t rol32(uint32_t word, unsigned int shift)
+{
+	return (word << shift) | (word >> (32 - shift));
+}
+
+static uint32_t xfs_da_hashname(const uint8_t *name, int namelen)
+{
+	uint32_t hash;
+
+	for (hash = 0; namelen >= 4; namelen -= 4, name += 4)
+		hash = (name[0] << 21) ^ (name[1] << 14) ^ (name[2] << 7) ^
+		       (name[3] << 0) ^ rol32(hash, 7 * 4);
+
+	if (namelen) {
+		fprintf(stderr,
+			"internal error: "
+			"misbalanced input buffer to xfs_da_hashname - "
+			"overlapping %d bytes\n", namelen);
+		exit(1);
+	}
+
+	return hash;
+}
+
+static uint8_t gen_rand(void)
+{
+	uint8_t r;
+	while (!(r = rand()));
+	return r;
+}
+
+static uint8_t buffer[252+1] = {0};
+
+static void gen_name(void)
+{
+	int idx;
+	uint32_t hash, last;
+
+again:
+	for (idx = 0; idx < 252-4; idx+=4) {
+		buffer[idx + 0] = gen_rand();
+		buffer[idx + 1] = gen_rand();
+		buffer[idx + 2] = gen_rand();
+		buffer[idx + 3] = gen_rand();
+	}
+
+	hash = rol32(xfs_da_hashname(buffer, 248), 7 * 4);
+	last = hash ^ ~0U;
+
+	if (last == 0)
+		goto again;
+
+	buffer[idx + 3] = last & 0x7fU;
+	buffer[idx + 2] = (last >> 7)  & 0x7fU;
+	buffer[idx + 1] = (last >> 14) & 0x7fU;
+	buffer[idx + 0] = ((last >> 21) & 0xffU);
+
+	if (memchr(buffer, '.', sizeof(buffer)) ||
+	    memchr(buffer, '/', sizeof(buffer)))
+		goto again;
+
+	if (one_hash) {
+		/* very poor - can be improved later */
+		static bool done = false;
+		static uint32_t filter;
+
+		if (!done) {
+			filter = xfs_da_hashname(buffer, 252);
+			done = true;
+			return;
+		}
+
+		if (filter != xfs_da_hashname(buffer, 252))
+			goto again;
+	}
+}
+
+static int touch(const char *buffer)
+{
+	if (touch_mode == DIRECTORY) {
+		if (mkdir(buffer, S_IRWXU)) {
+			/* ignore if directory is already present */
+			if (errno == EEXIST)
+				return 0;
+			perror("mkdir with random directory name");
+			return 1;
+		}
+	} else if (touch_mode == FILENAME) {
+		int fd = creat(buffer, S_IRWXU);
+		if (fd == -1) {
+			/* ignore duplicate files */
+			if (errno == EEXIST)
+				return 0;
+			perror("creat with random directory name");
+			return 1;
+		}
+		if (close(fd)) {
+			perror("close is leaking a file descriptor");
+			return 1;
+		}
+		return 0;
+	}
+	return 0;
+}
+
+static void do_seed(void)
+{
+	struct timeval tv;
+	if (gettimeofday(&tv, NULL)) {
+		perror("gettimeofday");
+		exit(1);
+	}
+	srand(tv.tv_sec ^ tv.tv_usec ^ getpid());
+}
+
+static void usage_and_exit(const char *pname)
+{
+	fprintf(stderr, "usage: %s [-d] [-f] [-n num] [-s] directory\n"
+		        "\t-f\tcreate files (the default)\n"
+			"\t-d\tcreate directories\n"
+			"\t-n num\tcreate num directories or files (default 200000)\n"
+			"\t-s\tonly generate one hash\n"
+			"\tdirectory\tthe directory to chdir() to\n",
+		pname);
+	exit(1);
+}
+
+int main(int argc, char **argv)
+{
+	const char allopts[] = "hsdfn:";
+	int c, orig_cycles, errors = 0, cycles = 200000;
+
+	while ((c = getopt(argc, argv, allopts)) != -1) {
+		switch (c) {
+		case 'd':
+			if (touch_mode != ILLEGAL)
+				usage_and_exit(argv[0]);
+			touch_mode = DIRECTORY;
+			break;
+		case 'f':
+			if (touch_mode != ILLEGAL)
+				usage_and_exit(argv[0]);
+			touch_mode = FILENAME;
+			break;
+		case 'n':
+			errno = 0;
+			if (sscanf(optarg, "%d", &cycles) != 1 ||
+			    errno == ERANGE) {
+				fputs("could not parse number of iterations", stderr);
+				exit(1);
+			}
+			break;
+		case 's':
+			one_hash = true;
+			break;
+		default:
+			usage_and_exit(argv[0]);
+			break;
+		}
+	}
+
+	if (argc <= optind || touch_mode == ILLEGAL)
+		usage_and_exit(argv[0]);
+
+	if (chdir(argv[optind])) {
+		perror("chdir");
+		exit(1);
+	}
+
+	orig_cycles = cycles;
+
+	do_seed();
+
+	while (cycles--) {
+		gen_name();
+		errors += touch((char *)buffer);
+	}
+
+	if (errors)
+		fprintf(stderr, "creating %d %s caused %d errors\n",
+			orig_cycles, touch_mode == FILENAME ? "files" : "directories",
+			errors);
+
+	return 0;
+}
diff --git a/tests/xfs/307 b/tests/xfs/307
new file mode 100755
index 0000000..9ff1bf7
--- /dev/null
+++ b/tests/xfs/307
@@ -0,0 +1,63 @@
+#! /bin/bash
+# FS QA Test No. 307
+#
+# Test that directory hash entries are place in the correct order.
+# commit f5ea110 ("xfs: add CRCs to dir2/da node blocks") left the
+# directory with incorrect hash ordering.
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2014 Hannes Frederic Sowa.  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
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+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
+. ./common/repair
+
+# real QA test starts here
+
+_supported_fs xfs
+_supported_os Linux
+_require_scratch
+
+_scratch_mkfs_xfs | _filter_mkfs 2>$tmp.mkfs
+_scratch_mount | _filter_scratch
+
+mkdir $SCRATCH_MNT/x
+$here/src/generate-hash-collision -d -n 10000 $SCRATCH_MNT/x
+umount $SCRATCH_MNT 2>&1 | _filter_scratch
+
+_scratch_xfs_repair 2>&1 | _filter_repair
+
+# success, all done
+status=0
+exit
diff --git a/tests/xfs/307.out b/tests/xfs/307.out
new file mode 100644
index 0000000..eaf5716
--- /dev/null
+++ b/tests/xfs/307.out
@@ -0,0 +1,28 @@
+QA output created by 307
+meta-data=DDEV isize=XXX agcount=N, agsize=XXX blks
+data     = bsize=XXX blocks=XXX, imaxpct=PCT
+         = sunit=XXX swidth=XXX, unwritten=X
+naming   =VERN bsize=XXX
+log      =LDEV bsize=XXX blocks=XXX
+realtime =RDEV extsz=XXX blocks=XXX, rtextents=XXX
+Phase 1 - find and verify superblock...
+Phase 2 - using <TYPEOF> log
+        - 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...
+        - process newly discovered inodes...
+Phase 4 - check for duplicate blocks...
+        - setting up duplicate extent list...
+        - check for inodes claiming duplicate blocks...
+Phase 5 - rebuild AG headers and trees...
+        - reset superblock...
+Phase 6 - check inode connectivity...
+        - resetting contents of realtime bitmap and summary inodes
+        - traversing filesystem ...
+        - traversal finished ...
+        - moving disconnected inodes to lost+found ...
+Phase 7 - verify and correct link counts...
+done
diff --git a/tests/xfs/group b/tests/xfs/group
index ba34650..a1ef7f9 100644
--- a/tests/xfs/group
+++ b/tests/xfs/group
@@ -189,3 +189,4 @@
 304 auto quick quota
 305 auto quota
 306 auto stress log metadata repair
+307 auto dir
-- 
1.9.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH v3 xfstests] add tests for unlinking directories with hash collisions
  2014-04-02 12:34     ` [PATCH v3 " Hannes Frederic Sowa
@ 2014-04-02 13:07       ` Mark Tinguely
  0 siblings, 0 replies; 16+ messages in thread
From: Mark Tinguely @ 2014-04-02 13:07 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: xfs

On 04/02/14 07:34, Hannes Frederic Sowa wrote:
> This tests creates several directories that have the same small (8)
> group of hashes to ensure the hash ordering of file and directories
> are preserved.
>
> Sample backtrace this test tries to prevent in future:
>
> [ 3856.245843] XFS (vda1): Internal error xfs_trans_cancel at line 966 of file fs/xfs/xfs_trans.c.  Caller 0xffffffffa01186bc
> [ 3856.249049] CPU: 1 PID: 866 Comm: rm Not tainted 3.13.6-200.fc20.x86_64 #1
> [ 3856.250966] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 3856.252615]  000000000000000c ffff8800d23a7d68 ffffffff8168730c ffff8800cf5462b8
> [ 3856.254823]  ffff8800d23a7d80 ffffffffa00d00cb ffffffffa01186bc ffff8800d23a7da8
> [ 3856.257241]  ffffffffa00e5459 ffff8800d9ac3400 ffff8800d23a7e30 ffff8800371b6800
> [ 3856.259420] Call Trace:
> [ 3856.260172]  [<ffffffff8168730c>] dump_stack+0x45/0x56
> [ 3856.261717]  [<ffffffffa00d00cb>] xfs_error_report+0x3b/0x40 [xfs]
> [ 3856.263472]  [<ffffffffa01186bc>] ? xfs_remove+0x1ac/0x370 [xfs]
> [ 3856.270838]  [<ffffffffa00e5459>] xfs_trans_cancel+0xd9/0x100 [xfs]
> [ 3856.272783]  [<ffffffffa01186bc>] xfs_remove+0x1ac/0x370 [xfs]
> [ 3856.274531]  [<ffffffffa00db40b>] xfs_vn_unlink+0x4b/0x90 [xfs]
> [ 3856.276286]  [<ffffffff811c61b8>] vfs_rmdir+0xa8/0x100
> [ 3856.277821]  [<ffffffff811c638d>] do_rmdir+0x17d/0x1d0
> [ 3856.281021]  [<ffffffff811ba7fe>] ? ____fput+0xe/0x10
> [ 3856.285261]  [<ffffffff8108c11c>] ? task_work_run+0xac/0xe0
> [ 3856.286952]  [<ffffffff81013a31>] ? do_notify_resume+0x61/0xa0
> [ 3856.288693]  [<ffffffff811c9a65>] SyS_unlinkat+0x25/0x40
> [ 3856.290407]  [<ffffffff816962e9>] system_call_fastpath+0x16/0x1b
> [ 3856.292685] XFS (vda1): xfs_do_force_shutdown(0x8) called from line 967 of file fs/xfs/xfs_trans.c.  Return address = 0xffffffffa00e5472
> [ 3856.627330] XFS (vda1): Corruption of in-memory data detected.  Shutting down filesystem
> [ 3856.627332] XFS (vda1): Please umount the filesystem and rectify the problem(s)
>
> With help from Mark Tinguely, thanks very much!
>
> Cc: Dave Chinner<david@fromorbit.com>
> Cc: Mark Tinguely<tinguely@sgi.com>
> Signed-off-by: Hannes Frederic Sowa<hannes@stressinduktion.org>
> ---
> Changelog:
>
> v2)
> * first serious proposal
>
> v3)
> * reduced number of possible generated hashes to 8 and thus lowered the number of
>    generated files to 10_000 which still generate the corruption in all of my
>    10 tests. This speeds up the test considerable. Maybe we can add
>    quick to the group description now?
> * updated changelog
>
> Also:
> When testing this program with reduced number of generated hashes and
> huge amount of test files, xfs_repair needs a considerable amount of
> time to check the directory (I aborted it). I guess this is because the
> hash tables get flattened to linked lists.
>
> I don't know if there are other runtime explosions in other parts of
> the code (maybe in the kernel).  I suggest to add a random perturbation
> to the hash function, which unluckily seems to be included into the
> superblock then, too.
>
> Please have a look!
>
> Thanks,
>
>    Hannes

Tested-by: Mark Tinguely <tinguely@sgi.com>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2014-04-02 13:07 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-27  7:41 xfs errors while unlinking filenames with hash collisions Hannes Frederic Sowa
2014-03-27 13:14 ` Mark Tinguely
2014-03-27 13:23   ` Hannes Frederic Sowa
2014-03-27 13:34     ` Mark Tinguely
2014-03-27 14:05       ` Hannes Frederic Sowa
2014-03-27 15:15         ` Mark Tinguely
2014-03-27 15:24           ` Hannes Frederic Sowa
2014-03-27 20:36             ` Mark Tinguely
2014-03-27 20:57             ` Mark Tinguely
2014-03-27 21:15               ` Hannes Frederic Sowa
2014-03-27 21:20                 ` Mark Tinguely
2014-04-01 18:49 ` [PATCH xfstests] tests for file hash collisions on xfs filesystems Hannes Frederic Sowa
2014-04-01 18:56   ` Mark Tinguely
2014-04-01 23:03   ` [PATCH v2 xfstests] add tests for unlinking directories with hash collisions Hannes Frederic Sowa
2014-04-02 12:34     ` [PATCH v3 " Hannes Frederic Sowa
2014-04-02 13:07       ` Mark Tinguely

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.