From: Aaron Straus <aaron@merfinllc.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Neil Brown <neilb@suse.de>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Trond Myklebust <trond.myklebust@fys.uio.no>,
LKML Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20
Date: Thu, 11 Sep 2008 11:49:52 -0700 [thread overview]
Message-ID: <20080911184951.GB19054@merfinllc.com> (raw)
In-Reply-To: <56258A29-95D5-4A8C-A097-014B8FEDFB8F@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Hi,
On Sep 11 01:48 PM, Chuck Lever wrote:
> Were you able to modify your writer to do real fsync system calls? If
> so, did it help? That would be a useful data point.
Yes/Yes. Please see the attached tarball sync-test.tar.bz2.
Inside you'll find the modified writer: writer_sync.py
That will call fsync on the file descriptor after each write.
Also I added the strace and wireshark data for the sync and nosync
cases.
Note these are all tested with latest linus git:
d1c6d2e547148c5aa0c0a4ff6aac82f7c6da1d8b
> Practically speaking this is often not enough for typical
> applications, so NFS client implementations go to further (non-
> standard) efforts to behave like a local file system. This is simply
> a question of whether we can address this while not creating
> performance or correctness issues for other common use cases.
Yep, I agree. I'm not saying what we do now is "wrong" per the RFC
(writing the file out of order). It's just different from what we've
done in the past (and somewhat unexpected).
I'm still hoping there is a simple fix... but maybe not... :(
Thanks!
=a=
--
===================
Aaron Straus
aaron@merfinllc.com
[-- Attachment #2: sync-test.tar.bz2 --]
[-- Type: application/octet-stream, Size: 15200 bytes --]
next prev parent reply other threads:[~2008-09-11 18:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-05 19:19 Aaron Straus
2008-09-05 19:56 ` [NFS] " Chuck Lever
2008-09-05 20:04 ` Aaron Straus
2008-09-05 20:36 ` Bernd Eckenfels
2008-09-05 20:36 ` Chuck Lever
2008-09-05 22:14 ` Aaron Straus
2008-09-06 0:03 ` Aaron Straus
2008-09-08 19:02 ` Aaron Straus
2008-09-08 21:15 ` Chuck Lever
2008-09-08 22:02 ` Aaron Straus
2008-09-09 19:46 ` Aaron Straus
2008-09-11 16:55 ` Chuck Lever
2008-09-11 17:19 ` Aaron Straus
2008-09-11 17:48 ` Chuck Lever
2008-09-11 18:49 ` Aaron Straus [this message]
2008-09-22 16:05 ` Hans-Peter Jansen
2008-09-22 16:35 ` Trond Myklebust
2008-09-22 17:04 ` Aaron Straus
2008-09-22 17:26 ` Chuck Lever
2008-09-22 17:37 ` Aaron Straus
2008-09-22 17:29 ` Trond Myklebust
2008-09-22 17:45 ` Aaron Straus
2008-09-22 18:43 ` Aaron Straus
2008-09-22 18:45 ` Hans-Peter Jansen
2008-09-22 18:45 ` Hans-Peter Jansen
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=20080911184951.GB19054@merfinllc.com \
--to=aaron@merfinllc.com \
--cc=chuck.lever@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trond.myklebust@fys.uio.no \
/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
all inboxes | Powered by JetHome®