From owner-freebsd-fs@FreeBSD.ORG Wed Sep 15 15:38:21 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 DD4961065675; Wed, 15 Sep 2010 15:38:21 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EA7618FC12; Wed, 15 Sep 2010 15:38:20 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA11317; Wed, 15 Sep 2010 18:38:17 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C90E869.8000400@freebsd.org> Date: Wed, 15 Sep 2010 18:38:17 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100909 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Steven Hartland 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> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90E328.20606@freebsd.org> In-Reply-To: <4C90E328.20606@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, jhell , Pawel Jakub Dawidek , freebsd-net@freebsd.org 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:38:21 -0000 on 15/09/2010 18:15 Andriy Gapon said the following: > on 15/09/2010 18:04 Steven Hartland said the following: >> Hmm, so taking a different track on the issue is the a way to make sendfile use data >> directly from ARC instead of having to copy it first? > > Well, theoretically everything is possible, but I am not sure if it's feasible. > It's a lot of work anyways, it should be a very specialized sendfile and a lot if > inter-layer knowledge and dependencies. > Don't hold your breath for it. Perhaps some middle-ground solution can be developed with less effort. This solution would be specific to filesystems that don't use buffer cache, so it wouldn't touch any pages, but instead it would use regular VOP_READ into a mbuf. So, there would be copying, but page caches won't be unnecessarily "polluted" with second copy of the data and this all would happen in kernel giving an advantage over userland solution with read(2)+send(2). Having said that, I see that OpenSolaris has a mechanism for something like that. The mechanism can either globally enabled or enabled for file over certain size. The mechanism uses dedicated kernel threads that get data using direct I/O, buffer and send it. That's my impression from a quick look, I may have gotten things wrong. -- Andriy Gapon