Hi,

I haven't followed all the details in this discussion, but it seems to me
that it all breaks down to:

- NFS on ZFS is slow due to NFS being very conservative when sending
  ACK to clients only after writes have definitely committed to disk.

- Therefore, the problem is not that much ZFS specific, it's just a
  conscious focus on data correctness vs. speed on ZFS/NFS' part.

- Currently known workarounds include:

  - Sacrifice correctness for speed by disabling ZIL or using a less
    conservative network file system.

  - Optimize NFS/ZFS to get as much speed as possible within the constraints
    of the NFS protocol.

But one aspect I haven't seen so far is: How can we optimize ZFS on a more
hardware oriented level to both achieve good NFS speeds and still preserve
the NFS level of correctness?

One possibility might be to give the ZFS pool enough spindles so it can
comfortably handle many small IOs fast enough for them not to become
NFS commit bottlenecks. This may require some tweaking on the ZFS side so
it doesn't queue up write IOs for too long as to not delay commits more than
necessary.

Has anyone investigated this branch or am I too simplistic in my view of the
underlying root of the problem?

Best regards,
   Constantin

-- 
Constantin Gonzalez                            Sun Microsystems GmbH, Germany
Platform Technology Group, Client Solutions                http://www.sun.de/
Tel.: +49 89/4 60 08-25 91                   http://blogs.sun.com/constantin/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to