On Mon, Oct 06, 2008 at 06:01:54PM -0700, Joel Becker wrote: > On Mon, Oct 06, 2008 at 07:32:48PM -0400, Theodore Tso wrote: > > On Mon, Oct 06, 2008 at 02:42:52PM -0700, Joel Becker wrote: > > I'm not 100% sure..... The other area that we should check very > > closely is jbd2_journal_commit_transaction(); in some cases, if > > jh->b_committed_data is NULL, the frozen data is thrown away (around > > line 850 in transaction.c). I *think* this happens if b_frozen_data > > was only copied to escape the buffer, but I'm not certain; in any > > case, there's a potential that in that case you might lose the > > calculated checksum and the correct value wouldn't get written to the > > final location on disk. <snip> > Looking at the checkpoint part, though, I think we're not safe. > The buffer is attached to the original transaction's checkpoint list > after the commit. This buffer has the un-checksummed b_data. If the > later transaction commits before the checkpoint happens, all is good. > But if the buffer lazily writes to disk while the later transaction is > still running, the original transaction could be considered "done", > updating the journal superblock. If we crash at that moment, we have a > bad checksum on disk. I chatted with Mark some about this today. He pointed out that, logically, b_data can't be checkpointed until its data isn't in the journal - it might be newer than the most recent transaction. So I looked in the checkpoint code to see where this is handled, and the checkpoint code simply forces a commit new enough to encompass b_data when it wants to put that block to disk. In other words, I think that the commit trigger is safe in all circumstances once moved up in journal_commit_transaction(). I'll be cooking that up shortly. Joel -- To spot the expert, pick the one who predicts the job will take the longest and cost the most. Joel Becker Principal Software Developer Oracle E-mail: joel.becker@xxxxxxxxxx Phone: (650) 506-8127 -- 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
