> It seems that you could still potentially get a failure to freeze if one > FUSE process depends on another, and the one that is frozen second just > happens to be waiting on the one that is frozen first when it is frozen. > I admit that this situation is unlikely, and perhaps acceptable. It isn't all that unlikely. There's sshfs for example, that depends on a separate ssh process for transport. Oh, there are also userspace network transports, like tun/tap, nfqueue, etc. They could block any network filesystem (not just fuse) if frozen first, making the freezer fail. Hmm, wonder why this isn't affecting people with VPNs? Probably network mounts over VPN are rare, and ever rarer to have fs activity on them during suspend. Anyway, I think it's long overdue to stop thinking about how to "fix" fuse, and concentrate on fixing the underlying problem instead ;) > A larger concern is that it seems that freezing FUSE processes at all > _will_ generate deadlocks if a non-synchronous or memory-map-supporting > filesystem is loopback mounted from a FUSE filesystem. In that case, if > you attempt to sync or free memory once FUSE is frozen, you are sure to > get a deadlock. Well, it would deadlock, if a) memory reclaim was synchronous, or b) large part of the memory was used for dirty file data I can't remember if (a) was ever true. And now the dirty ratio is 10% by default, so if we go OOM because that 10% can't be reclaimed, there is a more serious problem. Swap over loop over fuse would be problematic, but that won't work for some time yet ;) Miklos _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
