[3861] in arla-drinkers
Re: is cache-only-prefixes an nnpfs limitation?
daemon@ATHENA.MIT.EDU (Tomas Olsson)
Wed Apr 5 03:57:27 2006
From arla-drinkers-bounces@stacken.kth.se Wed Apr 05 07:57:26 2006
Return-Path: <arla-drinkers-bounces@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 17197 invoked from network); 5 Apr 2006 07:57:26 -0000
Received: from mx1.kth.se (130.237.32.140)
by charon.mit.edu with SMTP; 5 Apr 2006 07:57:26 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
by mx1.kth.se (Postfix) with ESMTP id ED21E140DF2;
Wed, 5 Apr 2006 09:57:24 +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 24606-01-40; Wed, 5 Apr 2006 09:57:21 +0200 (CEST)
Received: from tapas.stacken.kth.se (tapas.stacken.kth.se [130.237.234.140])
by mx1.kth.se (Postfix) with ESMTP id 83310141A40;
Wed, 5 Apr 2006 09:57:09 +0200 (CEST)
Received: from tapas.stacken.kth.se (localhost [127.0.0.1])
by tapas.stacken.kth.se (Postfix) with ESMTP id 17B8B534F3;
Wed, 5 Apr 2006 09:57: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 805B3534F3
for <arla-drinkers@tapas.stacken.kth.se>;
Wed, 5 Apr 2006 09:57:06 +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 k357v5bB026076
for <arla-drinkers@stacken.kth.se>;
Wed, 5 Apr 2006 09:57:05 +0200 (MET DST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by mx2.kth.se (Postfix) with ESMTP id AD198140CE7
for <arla-drinkers@stacken.kth.se>;
Wed, 5 Apr 2006 09:57:05 +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 25972-01-37; Wed, 5 Apr 2006 09:57:03 +0200 (CEST)
Received: from kashyyyk.ite.kth.se (kashyyyk.ite.kth.se [130.237.31.35])
by mx2.kth.se (Postfix) with ESMTP id B975A140C87;
Wed, 5 Apr 2006 09:57:03 +0200 (CEST)
Received: by kashyyyk.ite.kth.se (Postfix, from userid 18404)
id 98C707C8632; Wed, 5 Apr 2006 09:57: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>
Date: 05 Apr 2006 09:57:03 +0200
In-Reply-To: <x33bgskjcm.fsf@nowhere.com>
Message-ID: <lsrpsjwsbe8.fsf@kashyyyk.ite.kth.se>
Lines: 44
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:
> Well, as long as it's eventually moving towards the point where it can
> fetch arbitrary blocks with some reasonably small blocksize, that's
> probably good enough.
>
At the moment I'm using 8k, but it probably won't get any smaller. The real
question is how large blocks one can use without latency getting too
painful. With the current quick-and-dirty design, there'll be a huge
performance hit and memory footprint on using small blocks. The plan is to
bother about cleverness once we know what to think about.
If you have any thoughts on the subject (protocol?), let me know.
> > AFAIK, w2k nnpfs works very well for demos and benchmarks, but it does have
> > threading issues. Needs some work to be fit for production use.
>
> Are there likely to be any data corruption, crashes, or hangs (due
> solely to nnpfs)? Or merely performance issues?
>
Stability things, races with multiple threads/users. The node locking
within nnpfs (and interfacing with ntfs) needs some polishing (IIRC). For
a single user it worked fine, like building emacs in AFS. As for
performance, it was pretty good at the time. Close to ntfs performance for
cached operations, and a huge margin to the OpenAFS client at the time. I
haven't done any benchmarking since, but a 14x performance gain for cached
reads is impressive, don't you think :)
> > If you happen to write up a little libnnpfs or so, I'm _very_ interested.
>
> Would you throw rotten vegetables at me if it happened to appear in
> the form of a native interface for Java code?
>
Not at all. Even if I was a C-only guy, it would be a good start. Actually,
the Keso people started to reimplement kesod in java, but it don't think
they finished anything. And java _is_ a fairly good choice for distributed
systems. Or Erlang.
> Something sort of like a cross between coda and sfs, but with a heavy
> emphasis on simplicity over performance. And the ability to tunnel
> over HTTP and DNS as last resorts.
>
Nice.
/t (previously a member of the jrockit team)
_______________________________________________
Arla-drinkers mailing list
Arla-drinkers@stacken.kth.se
https://lists.stacken.kth.se/mailman/listinfo/arla-drinkers
