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

[Miklos Szeredi <miklos@szeredi.hu>]

> >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.

No.

Just by making the filesystem not contribute to the dirty counters
(like ramfs), the deadlock problem can be solved.  In this case you
simply could not get a deadlock, because all those dirty pages
produced by the filesystem look just like normal allocations, which
simply cannot be touched when the userspace filesystem wants to
allocate more memory.

In this case the allocation would just fail.  Deadlock doesn't happen,
though the filesystem wasn't given any elevated privileges.

Of course this isn't a good situation: the memory is filled in with
dirty data of the filesystem which it cannot write back.  All sorts of
programs might fail because of the OOM situation, and the system could
even crash.

The hard part is ensuring that this doesn't happen, but that has
nothing to do with the userspace part of the filesystem.

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

I looked at ramfs, it isn't even limited.  You can easily crash your
system just by filling it up with data, but no deadlock will happen.
Same situation as described above.  Nothing strange about this, so I
don't really understand why people so vehemently believe that the
"userspace filesystem deadlock" phenomena cannot be solved.

> I don't see a theoretical problem, just some practical ones.
> 
> All can be overcome IMO, and it would be well worth it, too.

We are in agreement then :)

Thanks,
Miklos