From owner-freebsd-fs@FreeBSD.ORG Wed Sep 15 15:07:38 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F481065670 for ; Wed, 15 Sep 2010 15:07:38 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B813A8FC0C for ; Wed, 15 Sep 2010 15:07:37 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OvtaA-0005hz-Uk for freebsd-fs@freebsd.org; Wed, 15 Sep 2010 17:07:34 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2010 17:07:34 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2010 17:07:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Wed, 15 Sep 2010 17:07:28 +0200 Lines: 43 Message-ID: References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <4C90D3A1.7030008@freebsd.org> X-Enigmail-Version: 1.0.1 Subject: Re: zfs very poor performance compared to ufs due to lack of cache? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 15:07:38 -0000 On 09/15/10 16:09, Andriy Gapon wrote: > on 15/09/2010 16:42 Steven Hartland said the following: >>> General problem of double-caching with ZFS still remains and will remain and >>> nobody promised to fix that. >>> I.e. with sendfile (or mmap) you will end up with two copies of data, one in >>> page cache and the other in ARC. That happens on Solaris too, no magic. >> Obviously this is quite an issue as a 1GB source file will require 2GB of memory >> to stream hence totally outweighing any benefit of the zero copy sendfile offers? >> Indeed. Where would this need to be addressed as ufs doesn't suffer from this? > > In ZFS. But I don't think that this is going to happen any time soon if at all. > Authors of ZFS specifically chose to use a dedicated cache, which is ARC. > Talk to them, or don't use ZFS, or get used to it. > ARC has a price, but it supposedly has benefits too. (replying for the OPs benefit) This has been a question since the beginnings of ZFS on Solaris - the authors wanted their own control over the cache and hence the ARC was implemented (modified from the IBM's original). This decision has been contested as possibly ineffective but at the end it stayed. Here are some Googled references: http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg08692.html http://mail.opensolaris.org/pipermail/zfs-discuss/2009-July/029370.html There are also some problems which are curiously similar to ones people complain about in FreeBSD+ZFS: http://mail.opensolaris.org/pipermail/zfs-discuss/2009-July/029654.html http://mail.opensolaris.org/pipermail/zfs-discuss/2009-July/029362.html Random other references: http://www.almaden.ibm.com/cs/people/dmodha/arcfast.pdf http://nilesh-joshi.blogspot.com/2010/07/zfs-revisited.html http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg38362.html http://www.thezonemanager.com/2009/03/filesystem-cache-optimization.html