I don't like it either.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.
And I firmly believe that this can be done without having to specialI 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.
case filesystem serving processes.
There are already "strange" filesystems in the kernel which cannotAs others have mentioned, they are limited in the number of pages they are allowed to dirty.
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.
Of course, implementing this is probably not trivial. But I don't seeI don't see a theoretical problem, just some practical ones.
it as a theoretical problem as Linus does.