Re: is cache-only-prefixes an nnpfs limitation?

Adam Megacz <[email protected]> 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)