Le 7 juil. 09 à 15:21, Darren J Moffat a écrit :
Gaëtan Lehmann wrote:There will be two kinds of transfer protocol, once in production - CIFS and one specific to the application.But for a quick test, the test was made with scp.CIFS and scp are very different protocols with very different performance characteristics.Also really important is what the data access pattern is ? Is it read mostly or write mostly ? Are the files that are written accessed for read soon ? Is it sequential or random reads ?It is read mostly. Files are usually rarely accessed, but are likely to be accessed several times when they begin to be accessed. This is sequential read. The data set is transfered on the server, and the files are not modified after that (or very rarely). The whole data set is transfered at once.The data set is transfered in a little less than 3 minutes without compression - that's good! With compression, the data set is transfered in 15 minutes. I was hopping that a disk write cache can keep the transfer speed close to the 3 minutes obtained without compression.What is "good" by your definition ?That is a big difference and without seeing data my initial thought is that the system appears to be CPU bound, particularly if the only difference really was a compressed ZFS dataset versus an uncompressed one.Is "transfer" in this case a read from the server or a write to it ?
It is a write to the server. The server is cpu bound, because of the compression.
My workload is very simple: the user copy approximately 10GB of data on the server, and then only read it from time to time. During the copy on the server, the transfer is cpu bounded, and there is a lot of cpu time available when there is no copy to the server.Are you talking here about the server's CPU or the clients ?
I'm talking about the server's cpu. Client is not cpu bounded by scp.
> Using adisk to store the uncompressed data, as I guess it is done by the memory cache, may have helped.I thought the ZIL may have played this role.I think you are maybe confusing the ZIL and the L2ARC.
I think L2ARC is for reading data - I'd like an L2ARC for writing data.
What compression algorithm are you using ? The default "on" value of lzjb or are you doing something like gzip-9 ?
gzip-6. There is no speed problem with lzjb, but also not the same compression ratio :-)
Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66 fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr
PGP.sig
Description: Ceci est une signature électronique PGP
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
