On Thu, Sep 10, 2009 at 02:58:26PM -0400, Theodore Tso wrote: > On Thu, Sep 10, 2009 at 09:54:35PM +0530, Aneesh Kumar K.V wrote: > > > > But how would it work for fsync ? I mean > > > > I would expect for no journal mode ext4_sync_file should be doing > > simple_fsync(). That should be forcing the metadata buffer_heads > > via sync_mapping_buffers. And if we reuse these meta buffers we > > drop them the inode->mapping->private_list using bforget. > > > > But I don't see any of the above in code > > Aneesh, you're addressing a different problem than the one that Curt > were trying to deal with this patch. The problem we are worry about > is one where an inode's extent tree or indirect blocks are modified > right before the inode is deleted, and then one or more of those > metadata blocks get reallocated and written right away (most likely > this will happen via an O_DIRECT write), and then, because we didn't > use bforget(), the dirty metadata block in the buffer cache would get > written out, overwriting the O_DIRECT block. > > What you're worrying about, is a different issue. You're concerned > about the fact that since we are not associating an inode's extent > tree or indirect blocks with the inode, those blocks won't get forced > out to disk on an fsync() in ext4 no-journal mode. This may not be a > big deal for applications which expect to recover from an unclean > using mke2fs (and thus probably don't use fsync in any case), but > here's a patch to deal with the problem you've raised. > > - Ted But the patch you posted is using bforget which is removing the buffer_head from the inode->mapping->private_list. What i am trying to figure out is where does the buffer_head getting added to the private_list. ? -aneesh -- 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
