On Mon, 14 Apr 2014 00:22:42 -0700 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Fri, Apr 11, 2014 at 11:05:30PM +0200, Fabian Frederick wrote: > > Ok, that would mean 'older' filesystems -without barrier flag- > > to call generic_file_fsync would result in a flush but ext4 without journal > > also calls it ; maybe with nobarrier and I'm not sure it's the only case. > > How can I deal with this problem ? > > I don't really think not implementing the barrier option is a problem. > For ext4 if you want consistency either opencode generic_file_fsync > there and add the check, or add a __generic_file_fsync that doesn't > do the flush. I've been searching once again for generic_file_fsync callsites and EXT4 is the only filesystem with barrier flag calling generic_file_fsync. If Ted or Jan could tell me whether EXT4 without journal can issue the flush (blkdev_issue_flush) whatever option has been chosen for 'barrier' (as that option stands for journal barrier) -> simple case, just add blkdev_issue_flush. or if it requires looking at barrier flag in ext4/fsync.c In that case I'd be interested to know how (needs_barrier is based on journal flags) ... -> generic_file_fsync calls __generic_file_fsync (flush=true) -> ext4 calls __generic_file_fsync(false) if nobarrier. Fabian -- 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
