On Mon 22-04-13 12:11:11, Dmitry Monakhov wrote: > On Thu, 18 Apr 2013 20:07:27 +0200, Jan Kara <jack@xxxxxxx> wrote: > > On Wed 17-04-13 11:39:27, Dmitry Monakhov wrote: > > > On Mon, 15 Apr 2013 14:29:13 +0200, Jan Kara <jack@xxxxxxx> wrote: > > > > On Sun 14-04-13 23:01:34, Dmitry Monakhov wrote: > > > > > Current implementation of jbd2_journal_force_commit() is suboptimal because > > > > > result in empty and useless commits. But callers just want to force and wait > > > > > any unfinished commits. We already has jbd2_journal_force_commit_nested() > > > > > which does exactly what we want, except we are guaranteed that we do not hold > > > > > journal transaction open. > > > > Umm, I have a questions regarding this patch: > > > > Grep shows there are just two places in the code which use > > > > ext4_force_commit() (and thus jbd2_journal_force_commit()). These are > > > > ext4_write_inode() and ext4_sync_file() (in data=journal mode). The first > > > > callsite can use _nested() variant immediately as we even assert there's > > > > no handle started. The second call site can use the _nested variant as well > > > > because if we had the transaction started when entering ext4_sync_file() we > > > > would have serious problems (lock inversion, deadlocks in !data=journal > > > > modes) anyway. So IMO there's no need for !nested variant at all (at least > > > > in ext4, ocfs2 uses it as well, IMHO it can be converted as well but that's > > > > a different topic). Thoughts? > > > I'm not sure that I completely understand what you meant, but it seems > > > incorrect to use jbd2_journal_force_commit_nested() in > > > ext4_write_inode() and ext4_sync_file(). Because nested variant has > > > probabilistic behavior, It may skip real transaction commit if we hold > > > a transaction running. ext4_write_inode() and ext4_sync_file() > > > are the functions where we demand deterministic behavior. If we silently > > > miss real transaction commit because current->journal_info != NULL (due > > > to some bugs) this breaks data integrity assumptions and it is better to > > > make it loud and trigger a BUGON. > > I see. I was confused by the fact that 'nested' argument got used only in > > the assertion but now I see why that is. > Do you give me your ACK/Reviewed signature? Looking at it with a fresh mind I think there's still one bug: read_unlock(&journal->j_state_lock); if (need_to_start) - jbd2_log_start_commit(journal, tid); - jbd2_log_wait_commit(journal, tid); - return 1; + ret = jbd2_log_start_commit(journal, tid); + if (!ret) + ret = jbd2_log_wait_commit(journal, tid); jbd2_log_start_commit() will return 0 if it didn't wake jbd2 thread and 1 if it did. In either case we should call jbd2_log_wait_commit()... + if (!ret && progress) + *progress = 1; Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
