[lkml]   [2003]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Ext2-devel] [RFC] probably bug in current ext3/jbd


please, look:

thread A commit thread

if (jh->b_committed_data) {
jh->b_committed_data = NULL;
access for
b_committed_data == NULL ?

if (jh->b_frozen_data) {
jh->b_committed_data = jh->b_frozen_data;
jh->b_frozen_data = NULL;

or I miss something subtle here?

>>>>> Stephen C Tweedie (SCT) writes:

SCT> get_undo_access is a declaration of intention to modify the buffer.
SCT> When that happens, it calls do_get_write_access() with the force_copy
SCT> flag set. That means that it _always_ creates a new frozen_data copy of
SCT> the buffer the first time we get undo access to a bitmap buffer within
SCT> any given transaction. That basically means that for bitmaps,
SCT> frozen_data always holds the version of the buffer as of the end of the
SCT> previously completed transaction.

>> for_each_bh_in_forget_list() {
>> if (jh->b_committed_data) {
>> kfree(jh->b_committed_data);
jh-> b_committed_data = NULL;
>> }

SCT> Ah, but the *immediately* following lines are:

SCT> if (jh->b_frozen_data) {
jh-> b_committed_data = jh->b_frozen_data;
jh-> b_frozen_data = NULL;
SCT> }

SCT> so the frozen data that was preserved at get_undo_access() time has now
SCT> committed to disk and gets rotated into the b_committed_data version.
SCT> This is exactly how we get the new version of the committed data when
SCT> the old transaction commits.

SCT> Cheers,
SCT> Stephen

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.063 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site