lkml.org 
[lkml]   [2004]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] [Request for inclusion] Filesystem in Userspace
From
Date
> 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 special
case filesystem serving processes.

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.

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

Is there something which I'm missing here?

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

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.217 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site