> > 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
