From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 29 13:14:20 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C081065696 for ; Mon, 29 Sep 2008 13:14:20 +0000 (UTC) (envelope-from fbsd06+2H=66b76f71@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2F22A8FC16 for ; Mon, 29 Sep 2008 13:14:19 +0000 (UTC) (envelope-from fbsd06+2H=66b76f71@mlists.homeunix.com) Received: from gumby.homeunix.com. (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 97AF223E498 for ; Mon, 29 Sep 2008 09:14:18 -0400 (EDT) Date: Mon, 29 Sep 2008 14:14:15 +0100 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20080929141415.387f931f@gumby.homeunix.com.> In-Reply-To: <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> References: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> <5f67a8c40809282219w6ae93986od211c6e8c47066fe@mail.gmail.com> <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: experimantal question about md's X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2008 13:14:20 -0000 On Mon, 29 Sep 2008 10:36:46 +0200 "Michael Schuh" wrote: > so we have a webserver (par example) at this mirror it has very good > speed for the file-access > (ok i know in allmost cases is not the disk the bottleneck, and if we > could doing caching...) > at the above examle it is not really important if the write process > needs a second or two longer, > but by millions of requests it could be interseting to read the data > very fast...... That's exactly the case in which caching will work best. FreeBSD's integrated cache/VM system would keep such pages in memory even at the expense of writing other user data to swap. When I suggested a swap-backed device I was forgetting that malloc backed devices use memory that won't be paged, so there may be an advantage, but I think it would be the opposite to what you want. What it would do is keep rarely used file data in memory even if there's a better use for the memory elsewhere, so you would be trading performance for better worst-case latency.