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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
