From: Valerie Aurora Henson <vaurora@redhat.com> To: Theodore Tso <tytso@mit.edu>, Jamie Lokier <jamie@shareable.org>, Andrew Morton <akpm@linux-foundation.org>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Mason <chris.mason@oracle.com>, Eric Sandeen <sandeen@redhat.com>, Ric Wheeler <rwheeler@redhat.com> Subject: Re: [RFC PATCH] fpathconf() for fsync() behavior Date: Thu, 23 Apr 2009 12:16:12 -0400 [thread overview] Message-ID: <20090423161612.GG8476@shell> (raw) In-Reply-To: <20090423124230.GF2723@mit.edu> On Thu, Apr 23, 2009 at 08:42:30AM -0400, Theodore Tso wrote: > 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. I am sorry you were personally attacked over this issue - that was uncalled for and unproductive. I wish personal attacks were less common in open source. > 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! For example, Red Hat is beginning to support XFS officially, and I would be happy to fix any bugs we receive about applications failing to do fsync() before rename() - if I was sure I wasn't introducing a performance regression. -VAL
WARNING: multiple messages have this Message-ID (diff)
From: Valerie Aurora Henson <vaurora@redhat.com> To: Theodore Tso <tytso@mit.edu>, Jamie Lokier <jamie@shareable.org>, Andrew Morton <akpm@linux-foundation.org>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Mason < Subject: Re: [RFC PATCH] fpathconf() for fsync() behavior Date: Thu, 23 Apr 2009 12:16:12 -0400 [thread overview] Message-ID: <20090423161612.GG8476@shell> (raw) In-Reply-To: <20090423124230.GF2723@mit.edu> On Thu, Apr 23, 2009 at 08:42:30AM -0400, Theodore Tso wrote: > 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. I am sorry you were personally attacked over this issue - that was uncalled for and unproductive. I wish personal attacks were less common in open source. > 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! For example, Red Hat is beginning to support XFS officially, and I would be happy to fix any bugs we receive about applications failing to do fsync() before rename() - if I was sure I wasn't introducing a performance regression. -VAL
next prev parent reply other threads:[~2009-04-23 16:24 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-04-23 0:12 [RFC PATCH] fpathconf() for fsync() behavior Valerie Aurora Henson 2009-04-23 5:17 ` Andrew Morton 2009-04-23 11:21 ` Jamie Lokier 2009-04-23 12:42 ` Theodore Tso 2009-04-23 12:48 ` Jeff Garzik 2009-04-23 12:48 ` Jeff Garzik 2009-04-23 14:10 ` Theodore Tso 2009-04-23 16:16 ` Valerie Aurora Henson [this message] 2009-04-23 16:16 ` Valerie Aurora Henson 2009-04-26 9:26 ` Pavel Machek 2009-04-23 16:43 ` Jamie Lokier 2009-04-23 16:43 ` Jamie Lokier 2009-04-23 17:29 ` Theodore Tso 2009-04-23 20:44 ` fsync_range_with_flags() - improving sync_file_range() Jamie Lokier 2009-04-23 20:44 ` Jamie Lokier 2009-04-23 21:13 ` Theodore Tso 2009-04-23 21:13 ` Theodore Tso 2009-04-23 22:03 ` Jamie Lokier 2009-04-23 22:03 ` Jamie Lokier 2009-04-23 16:04 ` [RFC PATCH] fpathconf() for fsync() behavior Valerie Aurora Henson 2009-04-23 16:10 ` Ric Wheeler 2009-04-23 17:23 ` Jamie Lokier 2009-04-23 11:11 ` Christoph Hellwig 2009-04-23 15:49 ` Valerie Aurora Henson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090423161612.GG8476@shell \ --to=vaurora@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=chris.mason@oracle.com \ --cc=jamie@shareable.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rwheeler@redhat.com \ --cc=sandeen@redhat.com \ --cc=tytso@mit.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.