From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Kums <kumaran.rajaram@gmail.com>
Cc: Moazam Raja <moazam@gmail.com>, linux-nfs@vger.kernel.org
Subject: Re: O_DIRECT, O_SYNC, or fsync() on NFS mounts?
Date: Sat, 20 Nov 2010 18:54:04 -0500 [thread overview]
Message-ID: <1290297244.9269.9.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <AANLkTi=AV20AsUKOGfVg6M92T8LfPLuuyrG_hQESw_RU@mail.gmail.com>
On Sat, 2010-11-20 at 09:12 -0700, Kums wrote:
> On Fri, Nov 19, 2010 at 12:24 PM, Trond Myklebust <
> trond.myklebust@fys.uio.no> wrote:
>
> > On Thu, 2010-11-18 at 15:34 -0800, Moazam Raja wrote:
> > > Hi all,
> > >
> > > I'm currently exporting a ZFS filesystem on Solaris 11 Express as NFS.
> > > I have a Linux client mounting that NFS v3 filesystem with the
> > > proto=tcp option.
> > >
> > > My question is, what's the safest and most reliable way to write data
> > > to this NFS mount on a Linux client? Should my application code use
> > > O_DIRECT, or O_SYNC? Or should I be doing a write() and a fsync()? I
> > > want to make sure that data is not lost and is truly committed, while
> > > keeping decent performance (of course).
> >
> > Any one of the above methods will ensure that the data is synced to
> > disk. In addition, NFS also guarantees that your data is fully synced to
> > disk when taking/freeing POSIX locks, and when you close() the file.
> > --
> >
>
> Instead of enforcing at the application side with O_DIRECT/O_SYNC, what if
> we mount nfs client with -o sync option as well as exportfs the nfs server
> with sync option? This way the data from all the application can be
> guaranteed to be safe?
???????
What is your definition of 'safe' here? Do you mean 'everything written
by my application is guaranteed to hit disk'? If so, then that would be
a much stronger guarantee than POSIX and local disk give you, and it
will seriously impact I/O performance (whether you use NFS, local disk
or whatever).
Why do you need this kind of guarantee in the first place? What
applications are you running?
Trond
next prev parent reply other threads:[~2010-11-20 23:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 23:34 O_DIRECT, O_SYNC, or fsync() on NFS mounts? Moazam Raja
2010-11-19 19:24 ` Trond Myklebust
2010-11-19 19:55 ` Chuck Lever
2010-11-19 20:04 ` J. Bruce Fields
2010-11-19 21:26 ` Trond Myklebust
2010-11-19 21:48 ` J. Bruce Fields
2010-11-21 10:46 ` Christoph Hellwig
2010-11-21 19:31 ` Moazam Raja
2010-11-21 20:01 ` Trond Myklebust
[not found] ` <AANLkTi=AV20AsUKOGfVg6M92T8LfPLuuyrG_hQESw_RU@mail.gmail.com>
2010-11-20 23:54 ` Trond Myklebust [this message]
[not found] ` <AANLkTikFfdMWs0b4V1doVYUx1T96+ef8-dMUZf3v8cW9@mail.gmail.com>
2010-11-22 18:04 ` Trond Myklebust
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=1290297244.9269.9.camel@heimdal.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=kumaran.rajaram@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=moazam@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).