Joe Shamblin writes: > Roch - PAE wrote: > > William Shamblin writes: > > > I would make sure to check to see if ZFS over NFS meets your needs. We > > > have seen pretty bad performance numbers for writing over NFS to a ZFS > > > backed file system. It would pay to put it through the paces with a > > > typical work load. > > > > Can you quantify this statement, even roughly, If you change > > ZFS by UFS for the backing NFS filesystem ? > > Yes: > > un-afioing (430MB file) to Solaris nevada 50 (x86) running ZFS from > another x4200 running Solaris 10U2: > > Local ZFS: > afio: 432m+131k+843 bytes read in 137 seconds. The operation was successful. > > NFS->ZFS backing: > afio: 432m+131k+843 bytes read in 1895 seconds. The operation was > successful. > > NFS->UFS backing: > afio: 432m+131k+843 bytes read in 1670 seconds. The operation was > successful. > > Both the UFS and ZFS have terrible NFS numbers (I posted something about > this as well, and filed a report with Sun at least for Solaris 10)
This looks all _as designed_; It's not a solaris issue. If you find an NFS server that runs closer to 130 than to 1500 then it is not synching the data to disk when the client requests so (either because it has nvram like netapps, or it put data at risk and uses write-caches like some linux or like ZFS were you to run the server with zil_disable = 1 (gasp!)). > > Interestingly if you zil_disable to a machine that is running a UFS file > system (no ZFS present) you also seem to get a performance benefit: > > (untarring a 91MB file from Solaris 10U2 (x86) to nevada 50 (x86)) > root at gnathosaurus 11:04am % /bin/time gtar xfz /tmp/tetex-texmf.tar.gz > real 18:19.3 > user 2.4 > sys 10.1 > > (with zil_disable = 1) > root at gnathosaurus 11:44am % /bin/time gtar xfz /tmp/tetex-texmf.tar.gz > real 8:32.8 > user 2.4 > sys 10.4 Did you remove the xtracted files between runs ? Possibly the directory creation (first run) is causing this. -r
