In message <[EMAIL PROTECTED]>, "Andrew Morton" writes:
> Hi, J.
>
> I'd be interested in seeing some expansion on why shared mem was
> undesirable and why the NFS interface was not the way to go.
> Particularly the latter, as people have been suggesting this
> occasionally.
>
> This was thrashed through a number of months back on the gnome list.
> The debate concerned whether the exercise of unifying FTP/HTTP/etc with
> filesystems should be done in user space or the OS. User space won out
> (A VFS library, but limited to gnome apps only) because gnome is not
> just for linux.
>
> But the consensus was that if this were to be done in the OS, the NFS
> hook should be the way because that gives the best shot at cross-Unix
> portability.
I have some comments on this. My wrapfs is a wrapper stackable f/s with
hooks for a higher-level language. Wrapfs is ported to linux (2.[012]),
solaris, and freebsd, and offers the same functionality via its api. Ion
and I wrote several file systems using wrapfs, and their performance
(in-kernel) beats user-level nfs servers anywhere from 50% to 10x. Most of
the savings come from reduced context switches of course. For more info,
you can see my research Web page, and esp. the paper I'd be presenting at
Usenix in June: "Extending File Systems Using Stackable Templates." I also
have another paper which I'll be presenting next month at LinuxExpo (.org)
detailing the implementation of wrapfs for linux 2.1: "A Stackable File
System Interface For Linux."
As to the question of nfs vs. something else, I'd agree that the vnode f/s
interface is not the right api for f/s developers to use, esp. if you'd like
portability. My Wrapfs uses a simplified api to modify file data and file
names, but that's still not enough. My FiST (f/s translator) language can
describe file system at a higher level using an api that looks more like
system calls and NFS: read, write, lookup, unlink, mkdir, etc. Using that
common f/s description, it generates the right vnode-level code for whatever
OS wrapfs was ported to.
At a later date I intend to use fist to generate user-level nfs server code.
(I've had my share of user-level file servers: I maintain amd/am-utils and
wrote and maintain hlfsd.)
My research Web page is: http://www.cs.columbia.edu/~ezk/research/
> Another comment on the web page: s/lession/lesson/ :-)
>
> - Andrew.
PS. I'll be releasing a new wrapfs and kernel patches for 2.2.6 (new rename
code), as soon as Ion had a chance to verify my fixes.
Erez.
