Messages in this thread | | | Date | Tue, 15 Apr 2014 19:04:21 +0200 | From | Fabian Frederick <> | Subject | Re: [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
| |