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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
