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:3.735 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site