On 06/30/2014 01:55 PM, Ryusuke Konishi wrote: > On Mon, 30 Jun 2014 12:46:37 -0400, "Michael L. Semon" wrote: >> Hi! With debugging being discussed here, I wanted to pass on an issue >> that has no error message associated with it. This will be one of those >> error reports that Vyacheslav will find not too informative. He's >> been trying to help with those moments where NILFS2 will stop responding >> for no visible reason, but whatever issue has 100% reproducibility on >> my PC has no reproducibility on his PC. This is a new test; maybe this >> test will work. > <snip> >> After forcing a crash and collecting the core dump, I see this using >> the crash 7.0.4 program: >> >> crash> bt 274 >> PID: 274 TASK: dd9caac0 CPU: 0 COMMAND: "segctord" >> #0 [c0063d48] __schedule at c1641357 >> #1 [c0063dc8] schedule at c1641a7e >> #2 [c0063dd0] inode_wait at c11467c8 >> #3 [c0063dd8] __wait_on_bit at c1642133 >> #4 [c0063df0] __inode_wait_for_writeback at c1156d98 >> #5 [c0063e24] inode_wait_for_writeback at c1159fff >> #6 [c0063e34] evict at c11475de >> #7 [c0063e48] iput at c11482ef >> #8 [c0063e60] nilfs_dispose_list at c12f104a >> #9 [c0063ecc] nilfs_transaction_unlock at c12f14e9 >> #10 [c0063edc] nilfs_segctor_thread at c12f3fa1 >> #11 [c0063f28] kthread at c105fb56 >> #12 [c0063fb0] ret_from_kernel_thread at c164729e >> >> crash> bt 301 >> PID: 301 TASK: dd9cc020 CPU: 0 COMMAND: "sync" >> #0 [de9e1dac] __schedule at c1641357 >> #1 [de9e1e2c] schedule at c1641a7e >> #2 [de9e1e34] schedule_timeout at c1640a80 >> #3 [de9e1ea8] wait_for_completion at c1642436 >> #4 [de9e1ed4] sync_inodes_sb at c115ae12 >> #5 [de9e1f7c] sync_inodes_one_sb at c115e620 >> #6 [de9e1f84] iterate_supers at c112d1e8 >> #7 [de9e1fa0] sys_sync at c115e85c >> #8 [de9e1fb0] ia32_sysenter_target at c164736b >> EAX: 00000024 EBX: bf8b1954 ECX: 00000000 EDX: b775517c >> DS: 007b ESI: 00000001 ES: 007b EDI: 00000000 >> SS: 007b ESP: bf8b187c EBP: bf8b18b8 GS: 0000 >> CS: 0073 EIP: b776da8c ERR: 00000024 EFLAGS: 00000246 > > Uum, this seems a deadlock issue over I_SYNC flag on inode->i_state. > If so, the issue looks reproducible also for default mount by calling > sync command and removing files repeatedly. > > Can you try it ? > > Regards, > Ryusuke Konishi It was fine on the default mount. The script above was used until a 4GB partition was 65% full. Then, I added more threads and populated it again until the filesystem ran out of space. No problems. In case you or Vyacheslav need the kernel config, it is here: https://drive.google.com/file/d/0B41268QKoNjtSUE0SkZsb0E5ckE I had a similar issue with xfstests; one of the stack traces may have ended with "no locks were held by segctord/8879." However, those files did not make it to my USB key to bring here. They will be included next time, so that I can verify that message. [My memory is not very good at times.] Thanks again! Michael -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
