From owner-freebsd-net@FreeBSD.ORG  Tue Sep 21 11:25:07 2010
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 457661065670;
	Tue, 21 Sep 2010 11:25:07 +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 4760A8FC0A;
	Tue, 21 Sep 2010 11:25:05 +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 OAA03935;
	Tue, 21 Sep 2010 14:25:03 +0300 (EEST)
	(envelope-from avg@freebsd.org)
Message-ID: <4C98960F.9020404@freebsd.org>
Date: Tue, 21 Sep 2010 14:25:03 +0300
From: Andriy Gapon <avg@freebsd.org>
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: Andre Oppermann <andre@freebsd.org>
References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><AANLkTikNhsj5myhQCoPaNytUbpHtox1vg9AZm1N-OcMO@mail.gmail.com><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><A6D7E134B24F42E395C30A375A6B50AF@multiplay.co.uk><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org>	<B98EBECBD399417CA5390C20627384B1@multiplay.co.uk>	<D79F15FEB5794315BD8668E40B414BF0@multiplay.co.uk>	<4C90B4C8.90203@freebsd.org>	<6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk>	<4C90D3A1.7030008@freebsd.org>	<0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk>	<4C90E328.20606@freebsd.org>
	<4C90E869.8000400@freebsd.org> <4C90EDA1.6020501@freebsd.org>
	<4C90F4F6.209@freebsd.org>
In-Reply-To: <4C90F4F6.209@freebsd.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org,
	Konstantin Belousov <kib@freebsd.org>
Subject: Re: zfs very poor performance compared to ufs due to lack of cache?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Sep 2010 11:25:07 -0000

on 15/09/2010 19:31 Andriy Gapon said the following:
> on 15/09/2010 19:00 Andre Oppermann said the following:
>> Is there a quick way of deciding within sendfile(2) whether a file resides
>> on a filesystem that doesn't use the buffer cache?
> 
> I don't know of any reliable way to do it.
> 

If I understood correctly what Kostik suggested in a chat, then we could abstract
core sendfile<->vm<->fs logic into a new vop, say vop_sendpages (don't mind the
name much).
std_sendpages would do what code in kern_sendfile does today and would be used by
most of filesystems.  But some filesystems could override it e.g. to avoid using
VM page cache.
Or, perhaps, we could even add EXT_ZFSARC type of mbuf that would know how to work
with data buffers held in ARC and unhold them when done.  That would make sendfile
work on ZFS through a single cache.

-- 
Andriy Gapon