Interesting...from what I had read about NFSv3 asynchronous writes, especially bits about "does not require the server to commit to stable storage", led me to expect different behavior. The performance impact on large writes (which we do a lot of) wasn't severe, so sync=disabled is probably not worth the risk. The SSDs should also be able to take a fair amount of abuse, so I can live with the behavior as-is.
Here's one example of documentation that led me to expect something else: http://nfs.sourceforge.net/ , search for "unstable". It did indeed seem like the nfs client was delaying writes, then doing synchronous nfs calls, which is why I looked into the packets with wireshark (and found them to be advertised as "UNSTABLE", but with the pool acting synchronous). Thanks, Tim On Wed, Jun 13, 2012 at 6:51 PM, Daniel Carosone <d...@geek.com.au> wrote: > > On Wed, Jun 13, 2012 at 05:56:56PM -0500, Timothy Coalson wrote: > > client: ubuntu 11.10 > > /etc/fstab entry: <server>:/mainpool/storage /mnt/myelin nfs > > bg,retry=5,soft,proto=tcp,intr,nfsvers=3,noatime,nodiratime,async > > 0 > > 0 > > nfsvers=3 > > > NAME PROPERTY VALUE SOURCE > > mainpool/storage sync standard default > > sync=standard > > This is expected behaviour for this combination. NFS 3 semantics are > for persistent writes at the server regardless - and mostly also > for NFS 4. > > The async client mount option relates to when the writes get shipped > to the server (immediately or delayed in dirty pages), rather than to > how the server should handle those writes once they arrive. > > You could set sync=disabled if you're happy with the consequences, or > even just as a temporary test to confirm the impact. It sounds like > you would be since that's what you're trying to achieve. > > There is a difference: async on the client means data is lost on a > client reboot, async on the server means data may be lost on a server > reboot (and the client/application confused by inconsistencies as a > result). > > Separate datasets (and mounts) for data with different persistence > requirements can help. > > -- > Dan. > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
