On Jun 12, 2007, at 12:57 AM, Roch - PAE wrote:
Hi Seigfried, just making sure you had seen this:
http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine
You have very fast NFS to non-ZFS runs.
That seems only possible if the hosting OS did not sync the
data when NFS required it or the drive in question had some
fast write caches. If the drive did have some FWC and ZFS
was still slow using them, that would be the issue with
flushing mention in the blog entry.
but also maybe there is something to be learned from the
Samba and AFP results...
Takeaways:
ZFS and NFS just work together.
ZFS has an open issue with some storage array (the
issue is *not* related to NFS); it's being worked
on. Will need collaboration from storage vendors.
NFS is slower than direct attached. Can be very very
much slower on single threaded loads.
Roch knows this, but just to point out for others following the
discussion...
In this case (single threaded file creates) NFS is slower. However,
NFS can go at 1Gbe wirespeed, which can be faster than your disks
(depending how many spindles you have and if you've striped them for
performance).
There are many ways to workaround the slowness but most
are just not safe for your data.
Yeah, the samba numbers were interesting... so i guess its ok in CIFS
for the client to be out of sync with the server? That is, i wonder
how they handle the case where the client creates a file, server
replies ok w/out the data/metadata going to stable storage, server
crashes, comes back up, created file is not on stable storage but the
client (and its app) thinks it exists...
I really would like to know the details of CIFS behavior compared to
NFS...
eric
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
