From owner-freebsd-arch@FreeBSD.ORG Thu Mar 1 14:32:36 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48764106564A; Thu, 1 Mar 2012 14:32:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 82FA68FC15; Thu, 1 Mar 2012 14:32:34 +0000 (UTC) Received: by lagv3 with SMTP id v3so1128172lag.13 for ; Thu, 01 Mar 2012 06:32:33 -0800 (PST) Received-SPF: pass (google.com: domain of asmrookie@gmail.com designates 10.152.130.234 as permitted sender) client-ip=10.152.130.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of asmrookie@gmail.com designates 10.152.130.234 as permitted sender) smtp.mail=asmrookie@gmail.com; dkim=pass header.i=asmrookie@gmail.com Received: from mr.google.com ([10.152.130.234]) by 10.152.130.234 with SMTP id oh10mr5287243lab.35.1330612353335 (num_hops = 1); Thu, 01 Mar 2012 06:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CF49K3DG02gnM8s0VOwA8l3F/1p+FTtEU/X2ha2/Gl0=; b=XdzsmARVScG7NzwxZEDa4bbrIMotavnW0JUFPi1dkuEiEAnIhGsibGGkGbZi3WcR/k PXHqi8ew3amXf8w+Zn/AjyeyGZ0jkkIowWeio8yp8AWLl82N/cQ1NBgKNpQjk/sahuJ5 Rm2Qm1Eza0V9nmtmdhxKz/vx/cHR4S2vxtYBE= MIME-Version: 1.0 Received: by 10.152.130.234 with SMTP id oh10mr4299652lab.35.1330612353193; Thu, 01 Mar 2012 06:32:33 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.41.5 with HTTP; Thu, 1 Mar 2012 06:32:33 -0800 (PST) In-Reply-To: <20120301141247.GE1336@garage.freebsd.pl> References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> <20120225151334.GH1344@garage.freebsd.pl> <20120225194630.GI1344@garage.freebsd.pl> <20120301111624.GB30991@reks> <20120301141247.GE1336@garage.freebsd.pl> Date: Thu, 1 Mar 2012 14:32:33 +0000 X-Google-Sender-Auth: W8QAl2NJ7vStiNdX2HLNoulbfYk Message-ID: From: Attilio Rao To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , arch@freebsd.org, Gleb Kurtsou Subject: Re: Prefaulting for i/o buffers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:32:36 -0000 2012/3/1, Pawel Jakub Dawidek : > On Thu, Mar 01, 2012 at 01:16:24PM +0200, Gleb Kurtsou wrote: >> On (25/02/2012 20:46), Pawel Jakub Dawidek wrote: >> > - "Every file system needs cache. Let's make it general, so that all >> > file >> > systems can use it!" Well, for VFS each file system is a separate >> > entity, which is not the case for ZFS. ZFS can cache one block only >> > once that is used by one file system, 10 clones and 100 snapshots, >> > which all are separate mount points from VFS perspective. >> > The same block would be cached 111 times by the buffer cache. >> >> Hmm. But this one is optional. Use vop_cachedlookup (or call >> cache_entry() on your own), add a number of cache_prune calls. It's >> pretty much library-like design you describe below. > > Yes, namecache is already library-like, but I was talking about the > buffer cache. I managed to bypass it eventually with suggestions from > ups@, but for a long time I was sure it isn't at all possible. Can you please clarify on this as I really don't understand what you mean? > >> Everybody agrees that VFS needs more care. But there haven't been much >> of concrete suggestions or at least there is no VFS TODO list. > > Everybody agrees on that, true, but we disagree on the direction we > should move our VFS, ie. make it more light-weight vs. more heavy-weight. All I'm saying (and Gleb too) is that I don't see any benefit in replicating all the vnodes lifecycle at the inode level and in the filesystem specific implementation. I don't see a semplification in the work to do, I don't think this is going to be simpler for a single specific filesystem (without mentioning the legacy support, which means re-implement inode handling for every filesystem we have now), we just loose generality. if you want a good example of a VFS primitive that was really UFS-centric and it was mistakenly made generic is vn_start_write() and sibillings. I guess it was introduced just to cater UFS snapshot creation and then it poisoned other consumers. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein