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

[Avi Kivity <avi@argo.co.il>]

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.