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
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:
> Disk Write sequential data rate fsync: 0 4758.953878 MBytes/sec CpuUsage:
> 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
> 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.
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org