On Mon, Feb 12, 2018 at 08:12:58PM +0000, Terry Barnaby wrote:
On 12/02/18 17:35, Terry Barnaby wrote:
> On 12/02/18 17:15, J. Bruce Fields wrote:
> > On Mon, Feb 12, 2018 at 05:09:32PM +0000, Terry Barnaby wrote:
> > > One thing on this, that I forgot to ask, doesn't fsync() work
> > > properly with
> > > an NFS server side async mount then ?
> > No.
> >
> > If a server sets "async" on an export, there is absolutely no way for
a
> > client to guarantee that data reaches disk, or to know when it happens.
> >
> > Possibly "ignore_sync", or "unsafe_sync", or something
else, would be a
> > better name.
...
Just tried the use of fsync() with an NFS async mount, it appears to
work.
That's expected, it's the *export* option that cheats, not the mount
option.
Also, even if you're using the async export option--fsync will still
flush data to server memory, just not necessarily to disk.
With a simple 'C' program as a test program I see the
following data
rates/times when the program writes 100 MBytes to a single file over NFS
(open, write, write .., fsync) followed by close (after the timing):
NFS Write multiple small files 0.001584 ms/per file 0.615829 MBytes/sec
CpuUsage: 3.2%
Disktest: Writing/Reading 100.00 MBytes in 1048576 Byte Chunks
Disk Write sequential data rate fsync: 1 107.250685 MBytes/sec CpuUsage:
13.4%
Disk Write sequential data rate fsync: 0 4758.953878 MBytes/sec CpuUsage:
66.7%
Without the fsync() call the data rate is obviously to buffers and with the
fsync() call it definitely looks like it is to disk.
Could be, or you could be network-limited, hard to tell without knowing
more.
Interestingly, it appears, that the close() call actually does an
effective
fsync() as well as the close() takes an age when fsync() is not used.
Yes:
http://nfs.sourceforge.net/#faq_a8
--b.