[3875] in arla-drinkers
Re: is cache-only-prefixes an nnpfs limitation?
daemon@ATHENA.MIT.EDU (Tomas Olsson)
Mon Apr 10 03:45:11 2006
From arla-drinkers-bounces@stacken.kth.se Mon Apr 10 07:45:11 2006
Return-Path: <arla-drinkers-bounces@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 7623 invoked from network); 10 Apr 2006 07:45:11 -0000
Received: from mx2.kth.se (130.237.48.98)
by charon.mit.edu with SMTP; 10 Apr 2006 07:45:11 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
by mx2.kth.se (Postfix) with ESMTP id 74EE3140AA2;
Mon, 10 Apr 2006 09:45:10 +0200 (CEST)
Received: from mx2.kth.se ([127.0.0.1])
by localhost (mx2.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP
id 24917-01-72; Mon, 10 Apr 2006 09:45:08 +0200 (CEST)
Received: from tapas.stacken.kth.se (tapas.stacken.kth.se [130.237.234.140])
by mx2.kth.se (Postfix) with ESMTP id 427501406D4;
Mon, 10 Apr 2006 09:45:08 +0200 (CEST)
Received: from tapas.stacken.kth.se (localhost [127.0.0.1])
by tapas.stacken.kth.se (Postfix) with ESMTP id 14AB5534F3;
Mon, 10 Apr 2006 09:45:08 +0200 (CEST)
X-Original-To: arla-drinkers@tapas.stacken.kth.se
Delivered-To: arla-drinkers@tapas.stacken.kth.se
Received: from brev.stacken.kth.se (brev.stacken.kth.se [130.237.234.84])
by tapas.stacken.kth.se (Postfix) with ESMTP id 0D8ED534F3
for <arla-drinkers@tapas.stacken.kth.se>;
Mon, 10 Apr 2006 09:45:07 +0200 (CEST)
Received: from mx2.kth.se (mx2.kth.se [130.237.48.98])
by brev.stacken.kth.se (8.12.10/8.12.10) with ESMTP id k3A7j6la005478
for <arla-drinkers@stacken.kth.se>;
Mon, 10 Apr 2006 09:45:06 +0200 (MET DST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by mx2.kth.se (Postfix) with ESMTP id 3DDFA140AA2
for <arla-drinkers@stacken.kth.se>;
Mon, 10 Apr 2006 09:45:06 +0200 (CEST)
Received: from mx2.kth.se ([127.0.0.1])
by localhost (mx2.kth.se [127.0.0.1]) (amavisd-new,
port 10024) with LMTP
id 20727-01-73; Mon, 10 Apr 2006 09:45:04 +0200 (CEST)
Received: from kashyyyk.ite.kth.se (kashyyyk.ite.kth.se [130.237.31.35])
by mx2.kth.se (Postfix) with ESMTP id EB7DF1406D4;
Mon, 10 Apr 2006 09:45:03 +0200 (CEST)
Received: by kashyyyk.ite.kth.se (Postfix, from userid 18404)
id E058C7C8636; Mon, 10 Apr 2006 09:45:03 +0200 (CEST)
From: Tomas Olsson <tol@stacken.kth.se>
To: Adam Megacz <megacz@cs.berkeley.edu>
Subject: Re: is cache-only-prefixes an nnpfs limitation?
References: <x3mzf1bugb.fsf@nowhere.com> <lsrpsjxtyim.fsf@kashyyyk.ite.kth.se>
<x33bgskjcm.fsf@nowhere.com> <lsrpsjwsbe8.fsf@kashyyyk.ite.kth.se>
<x38xqetym2.fsf@nowhere.com> <lsrfykmpliu.fsf@kashyyyk.ite.kth.se>
<x364li48qs.fsf@nowhere.com>
Date: 10 Apr 2006 09:45:03 +0200
In-Reply-To: <x364li48qs.fsf@nowhere.com>
Message-ID: <lsry7ydoow0.fsf@kashyyyk.ite.kth.se>
Lines: 36
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at kth.se
X-Spam-Status: No, hits=-4.9 tagged_above=-200.0 required=5.0 tests=BAYES_00
X-Spam-Level:
Cc: arla-drinkers@stacken.kth.se
X-BeenThere: arla-drinkers@stacken.kth.se
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: Arla discussions <arla-drinkers.stacken.kth.se>
List-Unsubscribe: <https://lists.stacken.kth.se/mailman/listinfo/arla-drinkers>,
<mailto:arla-drinkers-request@stacken.kth.se?subject=unsubscribe>
List-Archive: <http://lists.stacken.kth.se/pipermail/arla-drinkers>
List-Post: <mailto:arla-drinkers@stacken.kth.se>
List-Help: <mailto:arla-drinkers-request@stacken.kth.se?subject=help>
List-Subscribe: <https://lists.stacken.kth.se/mailman/listinfo/arla-drinkers>,
<mailto:arla-drinkers-request@stacken.kth.se?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: arla-drinkers-bounces@stacken.kth.se
Errors-To: arla-drinkers-bounces@stacken.kth.se
X-Virus-Scanned: by amavisd-new at kth.se
Adam Megacz <megacz@cs.berkeley.edu> writes:
> Ok. Is it currently possible for the userspace to know when the
> kernel has read the block, so it can evict it immediately?
>
Not at the moment, but we should add such a pioctl. For the time being
there's the "flush file" pioctl.
> Hrm, why does linking to arlad enable this? Does arlad offer some
> extra undocumented interface to nnpfs?
>
One could implement a wrapper around open() that calls the
{Fetch,Store}Data rpc directly, but uses /afs for directory operations. No
nnpfs involved for the I/O, just pass your buffer to rx.
> So currently nnpfs makes a call to userspace every time it needs to
> find a cached block? I thought the thing that made this all work with
> acceptable performance was that the nnpfs kernel module already
> maintained such a cache (though very small)...
>
No, there is a cache, and we rarely need to call arlad for repeat reads.
Currently arlad takes care of all cache replacement things, on a node
level. The problem is that it's really nnpfs that gets all the syscalls and
knows what nodes are used, so arlad just somes up with nodes that it
*thinks* are not recently used, and says "can these be dropped?".
For blocks (especially when we start talking about files larger than your
cache) things get more complicated. So we figured it's time for nnpfs to
use the information available to it, and assume responsibility for the LRU.
But then there's the readahead that arlad has been responsible for, and
which nnpfs traditionally knows nothing about. And from the nnpfs side
there are writes/appends that consume cache space without arlad being
informed.
/t
_______________________________________________
Arla-drinkers mailing list
Arla-drinkers@stacken.kth.se
https://lists.stacken.kth.se/mailman/listinfo/arla-drinkers
