On Sun, 18 Mar 2001, Matt Dillon wrote:
> You could certainly write a program to sit in the middle and cache
> the request to handle that case.
>
> The problem with portalfs is that you can't 'cd' into it or do
> directory operations on it, and filesystem operations such as lseek,
> fstat, and so forth cannot be intercepted. It would be the ultimate
> coolness if you could.
>
> We need a better solution then faking an NFS mount to be able to run
> *real* filesystems in user space.
>
> But, that aside, portalfs works just dandy for getting simple file handles
> from a path.
Take a look at the XFS module included with Arla, and the Coda kernel
module. They're both targetted at the idea that a userspace daemon will
deal with open/close/directory requests, providing container vnodes for
the actual files on demand, allowing the kernel to efficiently provide
them to consumers. It's easy to imagine an HTTP backend daemon for them.
The Arla kernel module is probably a bit more mature and better
maintained; on the other hand, the Coda module is in our sys/ tree
already. The OpenBSD folk have actually imported Arla into their
distribution, which is actually not a bad idea now that OpenAFS is
around...
(Of course, we still need someone to port OpenAFS so that we have a free
server -- with IFS on the server side, we should be able to exhibit a
substantially simpler implementation with the same perform benefits as
the AFS iopen() stuff :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
