This thread started with the notion that ZFS provided a
very bad NFS service to the point of 10X degradation over
say UFS. What I hope we have an agreement on, is that these
scale of performance difference does not come from ZFS but
from an NFS service that would sacrifice integrity. Enabling
I should perhaps note that my last email on delegation describes the
optimisations possible under the NFSv4 protocol, as per RFC, all of
which are not necessarily implemented in our own Solaris client.
In particular, I think that fsync and committed writes do still go
through to the server,
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
Nope, wrong conclusion again.
This large performance degradation has nothing whatsoever to
do with ZFS. I have not seen data that would show a possible
slowness on the part of ZFS vfs AnyFS on the
backend; there may well be and that would be an entirely
diffenrent discussion to the large
Hi Roch,
thanks, now I better understand the issue :).
Nope. NFS is slow for single threaded tar extract. The
conservative approach of NFS is needed with the NFS protocol
in order to ensure client's side data integrity. Nothing ZFS
related.
...
NFS is plenty fast in a throughput
Roch - PAE wrote:
Not possible. Nothing related to ZFS here and if NFS had
ways to make this better i think it would have been done in v4.
If we extended the protocol to allow for exclusive mounts
(single client access) then, I would think that the extra
knowledge could be used to gain
We have had file delegation on by default in NFSv4 since Solaris 10 FCS,
putback in July 2004.
We're currently working on also providing directory delegations - client
caching of directory contents - as part of the upcoming NFSv4.1.
cheers,
calum.
Darren J Moffat wrote:
Roch - PAE wrote:
Bill,
I did the same test on the Thumper I'm working on with the NFS vols
converted from ZFS stripes to SVM stripes. In both cases same
number/type of disks in the stripe. In my very simple test ,time for
file in frame*; do cp /inq/$file /outq/$file; done, UFS did
approximately 64 MB/s,
Calum Mackay wrote:
We have had file delegation on by default in NFSv4 since Solaris 10 FCS,
putback in July 2004.
The delegation of a file gives the client certain guarantees about how
that file may be accessed by other clients (regardless of NFS version)
or processes local to the NFS
To accelerate NFS (in particular single threaded loads)
you need (somewhat badly) some *RAM between the Server FS and
it's storage; that *RAM is where NFS commited data may be stored.
If the *RAM does not survive a server reboot, the client is
at risk of seeing corruption.
For example, UFS
On Tue, 21 Nov 2006, Joe Little wrote:
On 11/21/06, Roch - PAE [EMAIL PROTECTED] wrote:
Matthew B Sweeney - Sun Microsystems Inc. writes:
Hi
I have an application that use NFS between a Thumper and a 4600. The
Thumper exports 2 ZFS filesystems that the 4600 uses as an inqueue
On Nov 22, 2006, at 4:11 PM, Al Hopper wrote:
No problem there! ZFS rocks. NFS/ZFS is a bad combination.
Has anyone tried sharing a ZFS fs using samba or afs or something
else besides nfs? Do we have the same issues?
Chad
---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting
On 11/22/06, Chad Leigh -- Shire.Net LLC [EMAIL PROTECTED] wrote:
On Nov 22, 2006, at 4:11 PM, Al Hopper wrote:
No problem there! ZFS rocks. NFS/ZFS is a bad combination.
Has anyone tried sharing a ZFS fs using samba or afs or something
else besides nfs? Do we have the same issues?
Yes, I've tried NFS and CIFS. I wouldn't call this a problem though. This is
the way it was designed to work to prevent loss of client data. If you want
faster performance put a battery-backed RAID card in your system and turn on
write-back caching on the card so that the RAM in the RAID
Have a gander below :
Agreed - it sucks - especially for small file use. Here's a 5,000 ft view
of the performance while unzipping and extracting a tar archive. First
the test is run on a SPARC 280R running Build 51a with dual 900MHz USIII
CPUs and 4Gb of RAM:
$ cp emacs-21.4a.tar.gz
On Nov 21, 2006, at 1:36 PM, Joe Little wrote:
On 11/21/06, Matthew B Sweeney - Sun Microsystems Inc.
[EMAIL PROTECTED] wrote:
Roch,
Am I barking up the wrong tree? Or is ZFS over NFS not the right
solution?
I strongly believe it is.. We just are at odds as to some philosophy.
16 matches
Mail list logo
