[3872] in arla-drinkers
Re: is cache-only-prefixes an nnpfs limitation?
daemon@ATHENA.MIT.EDU (Adam Megacz)
Sun Apr 9 19:40:51 2006
From arla-drinkers-bounces@stacken.kth.se Sun Apr 09 23:40:51 2006
Return-Path: <arla-drinkers-bounces@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 16079 invoked from network); 9 Apr 2006 23:40:51 -0000
Received: from mx2.kth.se (130.237.48.98)
by charon.mit.edu with SMTP; 9 Apr 2006 23:40:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
by mx2.kth.se (Postfix) with ESMTP id 1CCF61407E0;
Mon, 10 Apr 2006 01:40:50 +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 30343-01-6; Mon, 10 Apr 2006 01:40:48 +0200 (CEST)
Received: from tapas.stacken.kth.se (tapas.stacken.kth.se [130.237.234.140])
by mx2.kth.se (Postfix) with ESMTP id DD5601407D2;
Mon, 10 Apr 2006 01:40:47 +0200 (CEST)
Received: from tapas.stacken.kth.se (localhost [127.0.0.1])
by tapas.stacken.kth.se (Postfix) with ESMTP id 34295534F3;
Mon, 10 Apr 2006 01:40:47 +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 A8FB8534F3
for <arla-drinkers@tapas.stacken.kth.se>;
Mon, 10 Apr 2006 01:40:43 +0200 (CEST)
Received: from mx1.kth.se (mx1.kth.se [130.237.32.140])
by brev.stacken.kth.se (8.12.10/8.12.10) with ESMTP id k39Negla001696
for <arla-drinkers@stacken.kth.se>;
Mon, 10 Apr 2006 01:40:42 +0200 (MET DST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by mx1.kth.se (Postfix) with ESMTP id 842C714088E
for <arla-drinkers@stacken.kth.se>;
Mon, 10 Apr 2006 01:40:42 +0200 (CEST)
Received: from mx1.kth.se ([127.0.0.1])
by localhost (mx1.kth.se [127.0.0.1]) (amavisd-new,
port 10024) with LMTP
id 08940-01-26 for <arla-drinkers@stacken.kth.se>;
Mon, 10 Apr 2006 01:40:40 +0200 (CEST)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by mx1.kth.se (Postfix) with ESMTP id C388E1407E4
for <arla-drinkers@stacken.kth.se>;
Mon, 10 Apr 2006 01:40:40 +0200 (CEST)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1FSjWB-0004g9-3l
for arla-drinkers@stacken.kth.se; Mon, 10 Apr 2006 01:40:31 +0200
Received: from megacz.com ([216.237.119.186])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <arla-drinkers@stacken.kth.se>; Mon, 10 Apr 2006 01:40:31 +0200
Received: from megacz by megacz.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <arla-drinkers@stacken.kth.se>; Mon, 10 Apr 2006 01:40:31 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: arla-drinkers@stacken.kth.se
From: Adam Megacz <megacz@cs.berkeley.edu>
Subject: Re: is cache-only-prefixes an nnpfs limitation?
Date: Sun, 09 Apr 2006 16:41:47 -0700
Organization: Myself
Lines: 67
Message-ID: <x364li48qs.fsf@nowhere.com>
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>
Mime-Version: 1.0
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: megacz.com
X-Home-Page: http://www.megacz.com/
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)
Cancel-Lock: sha1:xWboXxsBKUo5giKd/uC/JRB+sBE=
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:
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
Tomas Olsson <tol@stacken.kth.se> writes:
> assumed to be a power of 2. For some reason I'm also assuming a 1:1
> mapping between (fid, offset) and cache "block" file.
That shouldn't be a problem in the short term, and actually this is
the correct approach in the long term if the underlying filesystem
handles small files properly (ie rieserfs). But for people using
ext3/vfat/ntfs to support the cache this may not scale. Not a
near-term concern though.
>> - If it is known that a remote file will only be read once, is it
>> possible to avoid writing it to the localfs disk?
> Later.
Ok. Is it currently possible for the userspace to know when the
kernel has read the block, so it can evict it immediately?
> The HPC folks are almost ready to kill for this (and cacheless writes).
> Right now they'll have to resort to linking against arlad to do it.
Hrm, why does linking to arlad enable this? Does arlad offer some
extra undocumented interface to nnpfs?
> The install messages aren't connected to the requests, there's a separate
> WAKEUP to say "it's done" or signal error. So most messages are standalone
> and can be used by the daemon without nnpfs requesting it. It's useful for
> readahead of data and stat nodes.
That is very, very cool.
> For now, we put one block in each cache file for simplicity.
>> complex mapping of (localfs_inode,offset)<->(remotefs_vnode,block#)?
> The offset "is" the block#, I'd say (cache block handle)<->(fid,offset)
I see! Thank you for clarifying this. This definately makes the
mapping simpler.
> We're not yet clear about how to implement the cache policies (LRU?), but
> the bookkeeping looks like it will be scary.
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)...
> If y'all want to split nnpfs discussions to new list, convince me. I just
> haven't seen a need yet.
No, that's fine; just wanted to make sure I was in the right place.
- a
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
_______________________________________________
Arla-drinkers mailing list
Arla-drinkers@stacken.kth.se
https://lists.stacken.kth.se/mailman/listinfo/arla-drinkers
