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 - 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/
