On Tue, Sep 08, 2009 at 11:21:11AM -0700, Curt Wohlgemuth wrote: > Hi Valerie: > > On Tue, Sep 8, 2009 at 10:56 AM, Valerie Aurora<vaurora@xxxxxxxxxx> wrote: > > Hey, did you figure this out? If not, I want to have a bug open > > somewhere. > > Yes, sorry. I was going to post a patch for this, but have been > waiting to verify that it really fixes the issue. And see the thread > started by Frank Mayhar about fsync issues as well... > > The problem is a race, between the last write to a to-be-freed > metadata block (to update the extent header) and the block being > marked free in the on-disk/buddy bitmaps. Note that this only happens > without a journal, since *with* a journal the ordering is done > correctly. Just to clarify, this a race that shows up even without an unclean shutdown, right? > Without a journal, the block buffer_head is written to, the > buffer_head is marked dirty, and the bitmaps are updated via > ext4_free_blocks(). In rare cases, the block is re-allocated for > another inode and written to -- subsequently, the writeback mechanism > will then flush the dirty extent header back to disk. That's why it > looks like "leaked extent data" in the data block. If this shows up even without an unclean shutdown, then it sounds like the problem is a missing bforget() call. - 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
