> > Actually there's also a non-malicious case in which waiting for
> > requests to finish won't work: when one fuse filesystem is accessing
> > another.
> >
> > Since we are blocking new fuse requests, that might block a fuse
> > daemon, which in turn makes it impossible to finish the pending
> > request.
>
> Hmm, yes, this is ugly. But will it hurt? We'll just wait for number
> of active fuse requests to go down to 0 before proceeding.
I'm thinking of the following situation, immediately after we begin to
wait for fuse requests to subside:
- task A is performing file operation O1
- O1 is being served by task B
- task B needs to perform O2 before finishing O1
Since we don't allow new requests, O2 will never start. So O1 will
never finish. So the number of fuse requests will never go to 0.
> It may still livelock on system with busy fused-s, but we'll detect
> that with timeout, and I believe it is 'don't do that' situation.
There are no busy fused's. If we allowed O2 to go through, everything
would be nice and dandy. But we cannot know that O2 needs to be let
through, and other fuse requests must not.
> > And this is not at all theoretical, I know that encfs is used over
> > various other fuse filesystems like sshfs or ntfs-3g.
> >
> > Yeah, stacking userspace filesystems could be done entirely in
> > userspace, and I'm actually working on that (with fuse-2.7.0 already
> > supporting some basic stacking).
>
> Great.
>
> > But the point is, that the "wait for fuse to quiescence" hack would
> > not work in todays environment.
>
> Ok, I'll just blame fuse here. 'You have to write to /sys
> files for SIGKILL to work' is not funny.
SIGKILL won't work on a stopped task. Neither on a traced task.
Neither on a zombie (how many newbies are thoroughly confused about
that ;)
And it won't work on a task that is hanging on an NFS mount, when the
network broke.
Oh, and it won't work on a deadlocked fuse filesystem. How many of
these have you met? How many of the others?
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
