Re: [PATCH] [Request for inclusion] Filesystem in Userspace

From: Avi Kivity
Date: Tue Nov 30 2004 - 13:51:56 EST

Miklos Szeredi wrote:

http://lkml.org/lkml/2004/7/26/68

discusses a userspace filesystem (implemented as a userspace nfs server mounted on a loopback nfs mount), the problem, a solution (exactly your suggestion), and a more generic solution.



Thanks for the pointer, very interesting read.

However, I don't like the idea that the userspace filesystem must
cooperate with the kernel in this regard. With this you lose one of
the advantages of doing filesystem in userspace: namely that you can
be sure, that anything you do cannot bring the system down.


I don't like it either.

And I firmly believe that this can be done without having to special
case filesystem serving processes.


I firmly believe the opposite. When a userspace process calls the kernel which (directly or indirectly) calls the userspace filesystem, the filesystem must have elevated priviledges, or it can deadlock when calling back in.

There are already "strange" filesystems in the kernel which cannot
really get rid of dirty data. I'm thinking of tmpfs and ramfs.
Neither of them are prone to deadlock, though both of them are "worse
off" than a userspace filesystem, in the sense that they have not even
the remotest chance of getting rid of the dirty data.



As others have mentioned, they are limited in the number of pages they are allowed to dirty.

Of course, implementing this is probably not trivial. But I don't see
it as a theoretical problem as Linus does.



I don't see a theoretical problem, just some practical ones.

All can be overcome IMO, and it would be well worth it, too.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/