On Thu, Mar 21, 2013 at 09:46:38PM +0100, Jan Kara wrote:
> Good catch! But shouldn't we rather fix jbd2_log_wait_commit() instead of
> inventing new function?
In most of the places where we call jbd2_log_start_commit(), we're
actually starting the current running transaction. So the fact that
we pass in a tid, and we're having to validate that the tid is
actually a valid one, is a bit of a waste. So in the long run I think
it's worth rethinking whether or not jbd2_log_{start,wait}_commit()
should exist in their current form, or whether we should reorganize
their functionality (i.e., by having a jbd2_start_running_commit(),
for example.). Piling on fixes to jbd2_log_wait_commit() would make
it get even more complicated, and I think if we separate out the
various ways in which we use these functions, we can make the code
simpler and easier to read.
In fact, I had started making this rather large set of changes when I
decided it would be better to save that kind of wholesale refactoring
for the next merge window. So the reason why I ended up fixing the
patch the way I did was to keep things simple.
Also as I mentioned in the commit description, by using a single
function I was also able to optimize the locking the locking somewhat.
- Ted
--
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
