The same operation runs so fast through SMB because SMB is returning backwith acknowledgment that I/O completed, whereas in reality the I/O might stillbe flying to disk, and might not even have made it to stable storage. In other words, SMB is lying to the I/O requestor. NFS, on the other hand, is POSIX compliant, and that means that it must absolutelyand with no ifs, buts, or maybes commit the I/O to disk before it may acknowledgethat the I/O request completed. In other words, lying is not allowed. Read all about it here: http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine
Date: Fri, 29 Jan 2010 08:54:25 +0100 From: [email protected] To: ug-chosug at opensolaris.org Subject: [ug-chosug] [NFS] Zfs sharenfs bad performance Hi there, When i say bad, this is really bad... I'm sharing a dataset trough zfs sharenfs. I connected a MacOSX client, and tested reads and writes. Performances are far below what i'd expect from my gigabit network... Every writes and deletion takes ages to complete... To isolate the problem i fired up a script that creates 10000 100k files and delete them. Running this locally gives 0.400s for deletion and 24s for total time - creation + deletion. I actually locally mounted the NFS to see if this could come from OSX... And this is bad, the same script takes 8minutes over NFS :( - a bit worse from OSX client I also share another dataset from the same pool trough SMB and it's smoothly running at ~48MB/s I'm open to every idea. I already did a lot of inspection and nothing fancy got reported with snoop or nfsstat. Regards, Olivier _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/ug-chosug/attachments/20100129/b05bf201/attachment-0001.html>
