Hi,
On Tue, 2005-01-25 at 14:36, Alex Tomas wrote:
> Hi, could you review the following solution?
>
>
> t_outstanding_credits - number of _modified_ blocks in the transaction
> t_reserved - number of blocks all running handle reserved
> transaction size = t_outstanding_credits + t_reserved;
Ah, a work of genius.
Yes, this appears to cover all of the cases. It changes the semantics
of the jbd layer subtly: a handle isn't "charged" for its use of bh's
until it actually dirties them. But the handle is required to reserve
enough space up front in any case, so it shouldn't matter much exactly
when it gets charged. It _would_ affect journal_extend(), if that were
called between a journal_get_write_access() and a
journal_dirty_metadata(), but I don't think we do that anywhere, and the
change in behaviour ought to be merely a slight difference in when it's
legal to extend --- it shouldn't break the rules.
> journal_dirty_metadata(handle, bh)
> {
> transaction->t_reserved--;
> handle->h_buffer_credits--;
> if (jh->b_tcount > 0) {
> /* modifed, no need to track it any more */
> transaction->t_outstanding_credits++;
> jh->b_tcount = -1;
> }
> }
Actually, the whole thing can be wrapped in if (jh->b_tcount > 0) {}, I
think. If we have already charged the transaction for this buffer, then
there's no need to charge the handle for it again. That's going to be
particularly important for truncate(), where we are continually updating
the same blocks (eg. bitmap, indirect blocks), so we want to make sure
that after the first journal_dirty_metadata() call, no further charge is
made.
If we do that, do we in fact need t_reserved at all?
Very nice!
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
