lkml.org 
[lkml]   [2014]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] FS: Add generic data flush to fsync
On Mon, 14 Apr 2014 00:22:42 -0700
Christoph Hellwig <hch@infradead.org> 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


\
 
 \ /
  Last update: 2014-04-15 19:41    [W:0.046 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site