Hi! > > 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. > > I remain hopeful. :) Application developers *want* to do the right > thing in general; they are just facing a hopeless catch-22 right now. > The POSIX-ly correct use of fsync() exposes them to potential > multi-second delays on 95% of file systems currently in existence - > and the fsync() isn't even needed in many cases! Perhaps we should create documentation file explaining what kernel guarantees and what works mostly by mistake? For example (and I tried to watch the discussion...): On ext3 data=ordered, is "echo new > bar.new; mv -f bar.new bar " actually safe? Is it still safe on ext4 with workarounds, or is it that you just shrank the window? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
