Re: [RFC] relaxed barrier semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux