On 25-Apr-99 Andrew Morton wrote:
> 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.
Shared memory is bad becase it restricts the filesystem process to being on the
same machine as where the filesystem is mounted. While I decided that using
anything other than native encoding for the messages was a waste of time,
there's no reason why you can't have a translator to take it over the network.
Also adding SHM adds a second path between fs<->kernel<->user process, which
adds security and synchronization problems. SHM also interacts badly with the
page/buffer cache.
NFS is a viable option as a user-mode process protocol, but there's a couple of
reasons I didn't use it. For one, I wanted to experiment, and I didn't want to
deal with compatibility issues. Also, Linux NFS was very green at the time.
NFS has some inherent problems for this task as well. For one, the
statelessness makes some things very hard, particularly if the filesystem is
very dynamic. You basically have to try and encode everything into a handle
which was really only designed to hold a reference to a pre-existing object.
Its also has a very loose notion of cache coherency and consistency, whereas I
wanted to be able to have very dynamic filesystems where the process can be
involved with every operation if it wants to.
NFS is reasonably OK if you just want a usermode filesystem which behaves a lot
like a normal filesystem (ftp, automount, etc), but it's pretty poor for things
like a mail-reader filesystem.
> 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.
Well, HTTP is outright inappropriate for a filesystem interface of any form,
since it doesn't have a coherent namespace. It's certainly totally
incompatible with the kernel's notion of a namespace.
> 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.
Yeah, that's probably what I'd do. There's 4 options:
- user mode, with a special API
- user mode, with libc hacks
- kernel mode, with NFS
- kernel mode, with some other interface
Only the first 3 are really viable, and the middle 2 probably strike the best
balance between portability and generality. 4 has its uses, particularly if
you can steal someone else's "other interface", like CODA.
J
