All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Valerie Aurora Henson <vaurora@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Chris Mason <chris.mason@oracle.com>,
	Theodore Tso <tytso@mit.edu>, Eric Sandeen <sandeen@redhat.com>,
	Ric Wheeler <rwheeler@redhat.com>
Subject: Re: [RFC PATCH] fpathconf() for fsync() behavior
Date: Thu, 23 Apr 2009 12:21:05 +0100	[thread overview]
Message-ID: <20090423112105.GA1589@shareable.org> (raw)
In-Reply-To: <20090422221748.8c9022d1.akpm@linux-foundation.org>

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?

-- Jamie

  reply	other threads:[~2009-04-23 11:21 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 [this message]
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
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=20090423112105.GA1589@shareable.org \
    --to=jamie@shareable.org \
    --cc=akpm@linux-foundation.org \
    --cc=chris.mason@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rwheeler@redhat.com \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    --cc=vaurora@redhat.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.