Re: is cache-only-prefixes an nnpfs limitation?
Adam Megacz <[email protected]>
| Newsgroups | gmane.comp.file-systems.arla.general |
|---|---|
| Organization | Myself |
| Message-ID | <[email protected]> |
Tomas Olsson <[email protected]> writes: > Yup, the nnpfs implementation and protocol does limit things. It will get > less limiting, but I don't see us implementing completely free byte range > fetching. 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. > 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? > 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? Perhaps I shouldn't have mentioned this. ;) > What do you have in mind? 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. - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380