From: Andrew Morton <akpm@linux-foundation.org>
To: Steve Rago <sar@nec-labs.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Allow O_SYNC to be set by fcntl(F_SETFL)
Date: Fri, 8 Apr 2011 10:56:02 -0700 [thread overview]
Message-ID: <20110408105602.bb8f1b49.akpm@linux-foundation.org> (raw)
In-Reply-To: <4D9F4844.7090908@nec-labs.com>
On Fri, 08 Apr 2011 13:39:16 -0400
Steve Rago <sar@nec-labs.com> wrote:
> > I wonder if we should sync the file when someone sets O_SYNC this way.
> > If we don't then there is a period during which we have an fd which has
> > O_SYNC set, but it has pending unwritten data. An O_SYNC fd should
> > never be in such a state!
>
> Why not?
Because it's inconsistent. An O_SYNC fd never has outstanding writeout.
Except for in this one new and special time window between a setfl()
and the next write().
It's not a big deal, but it's somewhat ugly and merits thinking about.
> If I write something in non-synchronous mode, then change the file descriptor to synchronous mode, I should
> not make any assumptions about what was written prior to this point. If I care that much, I'll call fsync.
Well. You can call fsync() after every write() too.
> All that
> matters is that the operating system honors the contract as specified by the system call API.
There's a lot more to it than that. Things like
quality-of-implementation and principle-of-least-surprise. We used to
have a particular relationship between an O_SYNC fd and the state of
the inode which it represents. With this patch, that relationship no
longer holds.
As I say: not a big deal IMO, but it should be aired and thought about.
next prev parent reply other threads:[~2011-04-08 17:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-25 21:52 [PATCH] Allow O_SYNC to be set by fcntl(F_SETFL) Steve Rago
2011-04-07 21:37 ` Andrew Morton
2011-04-08 15:14 ` Christoph Hellwig
2011-04-08 17:39 ` Steve Rago
2011-04-08 17:56 ` Andrew Morton [this message]
2011-04-08 21:08 ` Christoph Hellwig
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=20110408105602.bb8f1b49.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sar@nec-labs.com \
/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: link
Be 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.