[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080911184951.GB19054@merfinllc.com>
Date: Thu, 11 Sep 2008 11:49:52 -0700
From: Aaron Straus <aaron@...finllc.com>
To: Chuck Lever <chuck.lever@...cle.com>
Cc: Neil Brown <neilb@...e.de>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
Trond Myklebust <trond.myklebust@....uio.no>,
LKML Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20
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@...finllc.com
Download attachment "sync-test.tar.bz2" of type "application/octet-stream" (15200 bytes)
Powered by blists - more mailing lists