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).
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
> > NAME PROPERTY VALUE SOURCE
> > mainpool/storage sync standard default
> 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
> Separate datasets (and mounts) for data with different persistence
> requirements can help.
zfs-discuss mailing list