On Saturday, 21 July 2007 20:12, Miklos Szeredi wrote: > > 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 ;) To conclude this branch of the thread, I have a patch in the works that may help a bit with unfreezable FUSE filesystems and it only affects the freezer. I'll post it when 2.6.23-rc1 is out, because it's on top of some other patches that need to go first. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
