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@xxxxxxxxxxxxx> Cc: Mark Tinguely<tinguely@xxxxxxx> Signed-off-by: Hannes Frederic Sowa<hannes@xxxxxxxxxxxxxxxxxxx> --- 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@xxxxxxx> _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
