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:2.352 / U:0.008 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site