lkml.org 
[lkml]   [2005]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: FUSE merging?
    From
    Date
    > > A dirty page is being written back, but the userspace server needs to
    > > allocate memory to complete the request. But the allocation will
    > > block, since there's no more free memory.
    >
    > That shouldn't happen with write() traffic due to the dirty memory
    > balancing logic.

    How? It either blocks other allocations until the writeback is
    completed (DoS) or allows memory to be exhausted (deadlock).

    Making unpriv mounts work securely is not a trivial thing I can tell
    you ;)

    > > User does unlink("/mnt/userfs/file"). Userspace server receives
    > > request to unlink "/file". Then the daemon does
    > > unlink("/mnt/userfs/file"). This will deadlock on i_sem.
    >
    > eh? How can the fuse client and the fuse server both get access to the
    > same file in this manner? I don't see how you could set that up with NFS,
    > for example.

    With a custom userspace NFS server you can do whatever you want.
    That's the whole purpose of the exercise.

    > > Because, I can well imagine a synthetic filesystem, where file
    > > data/metadata change aribitrarily. In this case the timeout heuristic
    > > in NFS is not useful.
    > >
    > > In fact with NFS it's often a PITA, that it doesn't want to refresh a
    > > file's data/metatata, which I _know_ has changed on the server.
    >
    > I think nfs can do this, as long as the modification was done through the
    > server. I'd expect v9fs would be the same.

    It's often not. Sshfs is a good example. File server will not be
    able to notify the client when anything changes. Polling is the only
    solution, and NFS doesn't always get it right (and in fact it cannot).
    It's much better to leave cache timeout policy to the userspace
    filesystem, then trying to guess it in the kernel.


    > > > Plus NFS and v9fs work across the network...
    > >
    > > Yes. I consider that a drawback.
    >
    > Others (many) would disagree.
    >
    >
    > Sorry, but I'm not buying it. I still don't see a solid reason why all
    > this could not be done with nfs/v9fs, some kernel tweaks and the rest in
    > userspace. It would take some effort, but that effort would end up
    > strengthening existing kernel capabilities rather than adding brand new
    > things, which is good.

    I'm not sure. NFS is a monster, everybody can agree. Getting all the
    requirements of FUSE (safe unprivileged mounts, etc) would be a
    nightmare.

    FUSE does one thing, and it does that right. I think that's good.

    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-07-01 14:06    [W:2.207 / U:0.384 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site