From: Dave Chinner <david@fromorbit.com>
To: Sage Weil <sage@newdream.net>
Cc: Indan Zupancic <indan@nul.nu>, Greg KH <greg@kroah.com>,
Jonathan Nieder <jrnieder@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
"Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>,
akpm@linux-foundation.org, linux-api@vger.kernel.org,
mtk.manpages@gmail.com, viro@zeniv.linux.org.uk, hch@lst.de,
l@jasper.es
Subject: Re: [PATCH v3] introduce sys_syncfs to sync a single file system
Date: Tue, 15 Mar 2011 21:11:55 +1100 [thread overview]
Message-ID: <20110315101155.GO15097@dastard> (raw)
In-Reply-To: <Pine.LNX.4.64.1103132114380.5145@cobra.newdream.net>
On Sun, Mar 13, 2011 at 09:29:17PM -0700, Sage Weil wrote:
> On Mon, 14 Mar 2011, Indan Zupancic wrote:
> > Everyone seems to want to add this new syncfs, but it's not even defined
> > what it does. "Same as sync, but only on one fs" is IMHO not good
> > enough, because sync's behaviour is pretty badly documented, and that's
> > a system call.
>
> How about the man page below? I tried to avoid the somewhat antiquated
> implementation specific terminology in the sync(2) man page.
>
> I think adding this functionality into sync_file_range(2) is forcing
> unrelated functionality into an existing interface; sync_file_range
> operates on _files_, not an entire file system. With each API addition it
> is more important to make the interface simple and intuitive than to
> minimize the size of our patches. IMO that's why a new syscall is
> preferable to, say, an equivalent ioctl.
>
> Thanks-
> sage
>
>
> .TH SYNCFS 2 2011-03-13 "Linux" "Linux Programmer's Manual"
> .SH NAME
> syncfs \- commit cached file system state to stable storage
> .SH SYNOPSIS
> .B #include <unistd.h>
> .sp
> .B void syncfs(int fd);
> .SH DESCRIPTION
> .BR syncfs ()
> flushes any cached data modifications to the file system containing the
> file referenced by the file descriptor
> .I fd
> to stable storage (usually a disk). This includes the results of any
> file modifications or other file system operations that have completed
> prior to the call to
> .BR syncfs(2).
> This is similar to
> .BR sync(2),
> but will commit changes for only a single file system instead of all
> mounted file systems.
> .SH ERRORS
> This function is always successful.
Perhaps we should consider propagating errors out to the user
application rather than discarding them in kernel and pretending we
can't ever have a write error?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2011-03-15 10:12 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-03 6:35 [RFC] introduce sys_syncat to sync a single file system Sage Weil
2011-03-03 7:22 ` Jonathan Nieder
2011-03-03 8:54 ` Aneesh Kumar K. V
2011-03-07 23:17 ` [RFC] introduce sys_syncfs to sync a single file system (v2) Sage Weil
2011-03-08 5:27 ` Aneesh Kumar K. V
2011-03-10 14:56 ` Arnd Bergmann
2011-03-10 19:28 ` Sage Weil
2011-03-10 19:31 ` [PATCH v3] introduce sys_syncfs to sync a single file system Sage Weil
2011-03-10 22:08 ` Arnd Bergmann
2011-03-11 4:44 ` Aneesh Kumar K. V
2011-03-11 11:01 ` Indan Zupancic
2011-03-11 11:55 ` Arnd Bergmann
2011-03-11 23:45 ` Indan Zupancic
2011-03-11 23:56 ` Jonathan Nieder
2011-03-12 1:53 ` Indan Zupancic
2011-03-12 2:10 ` Jonathan Nieder
2011-03-12 4:22 ` Indan Zupancic
2011-03-12 17:32 ` Greg KH
2011-03-14 1:56 ` Indan Zupancic
2011-03-14 4:29 ` Sage Weil
2011-03-14 9:27 ` Indan Zupancic
2011-03-14 10:22 ` Theodore Tso
2011-03-15 10:11 ` Dave Chinner [this message]
2011-03-15 13:00 ` Sage Weil
2011-03-15 15:56 ` Andreas Dilger
2011-03-15 16:08 ` Sage Weil
2011-03-15 20:18 ` Andrew Morton
2011-03-14 20:10 ` Andrew Morton
2011-03-14 20:29 ` Artem Bityutskiy
2011-03-14 21:11 ` Ted Ts'o
2011-03-14 21:20 ` Andrew Morton
2011-03-14 23:17 ` Ted Ts'o
2011-03-14 21:22 ` Arnd Bergmann
2011-03-12 0:40 ` Ric Wheeler
2011-03-12 1:33 ` Indan Zupancic
2011-03-12 2:52 ` Ric Wheeler
2011-03-12 3:50 ` Indan Zupancic
2011-03-12 12:41 ` Ric Wheeler
2011-03-12 18:31 ` Jeff Garzik
2011-03-14 1:31 ` Indan Zupancic
2011-03-14 1:37 ` Theodore Tso
2011-03-14 1:47 ` Indan Zupancic
2011-03-14 1:45 ` Jeff Garzik
2011-03-14 1:59 ` Indan Zupancic
2011-03-12 19:28 ` Artem Bityutskiy
2011-03-12 19:22 ` Artem Bityutskiy
2011-03-14 1:38 ` Indan Zupancic
2011-03-14 5:52 ` Artem Bityutskiy
2011-03-13 20:59 ` 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=20110315101155.GO15097@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=arnd@arndb.de \
--cc=greg@kroah.com \
--cc=hch@lst.de \
--cc=indan@nul.nu \
--cc=jrnieder@gmail.com \
--cc=l@jasper.es \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=sage@newdream.net \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox