On Thu 29-07-10 01:00:10, Christoph Hellwig wrote: > On Wed, Jul 28, 2010 at 02:47:20PM +0200, Jan Kara wrote: > > Well, ocfs2 uses jbd2 for journaling so it supports barriers out of the > > box and does not need the ordering. ocfs2_sync_file is actually correct > > (although maybe slightly inefficient) because it does > > jbd2_journal_force_commit() which creates and immediately commits a > > transaction and that implies a barrier. > > I don't think that's correct. ocfs2_sync_file first does > ocfs2_sync_inode, which does a completely superflous filemap_fdatawrite, > and from what I can see a just as superflous sync_mapping_buffers (given > that ocfs doesn't use mark_buffer_dirty_inode) and then might return > early in case we do fdatasync but the inode isn't marked > I_DIRTY_DATASYNC. In that case we might need a cache flush given > that the data might still be dirty. Ah, I see. You're right, fdatasync case is buggy. I'll send Joel a fix. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
