http://bugzilla.kernel.org/show_bug.cgi?id=14602 Summary: JBD2 journal abort / checkpoint creation racy? Product: File System Version: 2.5 Kernel Version: 2.6.32-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext4 AssignedTo: fs_ext4@xxxxxxxxxxxxxxxxxxxx ReportedBy: andi-bz@xxxxxxxxxxxxxx Regression: No I was testing a new file system feature that triggered IO errors on inode read. I did not actually change the abort part here so I believe this is unrelated to my changes. I had one case during testing where the journal abort didn't work and jbd2 journal abort errored out. <putting some stress on the file system> EXT4-fs error (device sda1): ext4_iget: triggering IO error EXT4-fs error (device sda1): ext4_put_super: Couldn't clean up the journal This happens in ext4_put_super->jbd2_journal_destroy->jbd2_log_do_checkpoint and then finally if (journal->j_sb_buffer) { if (!is_journal_aborted(journal)) { /* We can now mark the journal as empty. */ journal->j_tail = 0; journal->j_tail_sequence = ++journal->j_transaction_sequence; jbd2_journal_update_superblock(journal, 1); } else { err = -EIO; <------------ this is triggered } So it looks like jbd2_log_do_checkpoint sometimes does not succeed? It does a couple of retry, maybe that log is not enough. The problem is not easy to trigger unfortunately, i only saw it very rarely. I assume it's some race in the checkpoint creation. I tried to reproduce it with jbd2 debugging enabled, but no luck so far. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
