Re: [RFC PATCH] fpathconf() for fsync() behavior

[Theodore Tso]

On Thu, Apr 23, 2009 at 12:21:05PM +0100, Jamie Lokier wrote:
> Andrew Morton wrote:
> > Would it be better to implement new syscall(s) with finer-grained control
> > and better semantics?  Then userspace would just need to to:
> > 
> > 	fsync_on_steroids(fd, FSYNC_BEFORE_RENAME);
> > 
> > and that all gets down into the filesystem which can then work out what
> > it needs to do to implement the command.
> 
> +1 from me.  Several flags come to mind for discussion.
> FSYNC_HARDWARE.  FSYNC_ORDER_ONLY, FSYNC_FLUSH.
> FSYNC_DATA_BEFORE_SIZE.  FSYNC_BEFORE_NEW_FILE.
> 
> Nick Piggin was working on  fsync_range().
> 
> Maybe it's time to do fsync properly?

We could create such a thing, but how many application programmers
will actually *use* them?  People need to check out my blog, where my
competence, my judgement, even my paternity was questioned about this
issue.

Application writers don't care about OS portability (it only has to
work on Linux), or working on multiple filesystems (it only has work
on ext3, and any filesystems which doesn't do automagic fsync's at the
right magic times automagically is broken by design).  This includes
many GNOME and KDE developers.  So as we concluded at the filesystem
and storage workshop, we probably will have to keep automagic
hueristics out there, for all of the broken applications.  Heck, Linus
even refused to call those applications "broken".  

So we can create a more finer-grained controlled system call ---
although I would suggest that we just add some extra flags to
sync_file_range() --- but it's doubtful that many application
programmers will use it.

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/