On Thu, Jul 29, 2010 at 12:45:30PM +0200, Jan Kara wrote:
> 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.
I can certainly see our code being inefficient if the
handled-for-us behaviors of sync have changed. If the VFS is already
doing some work for us, maybe we don't need to do it. But we have to be
sure that these calls are always going through those paths. We sync our
files to disk when we drop cluster locks, regardless of whether there is
a userspace fsync().
I guess I never knew that data could be dirty without the
I_DIRTY_DATASYNC bit.
Joel
--
"Copy from one, it's plagiarism; copy from two, it's research."
- Wilson Mizner
Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker@xxxxxxxxxx
Phone: (650) 506-8127
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
