Hi. On Sunday 22 July 2007 04:12:22 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 ;) That's what I'm seeking to do :) > > 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 These are problems in normal operation, aren't they? > 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 ;) Hopefully people will wake up to the problems with Fuse and get rid of it before then :|. Of course I don't really expect that to happen. Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info.
Attachment:
pgpmwJZnsF5JY.pgp
Description: PGP signature
- References:
- Re: Hibernation considerations
- From: [email protected]
- Re: [linux-pm] Re: Hibernation considerations
- From: Jeremy Maitin-Shepard <[email protected]>
- Re: [linux-pm] Re: Hibernation considerations
- From: Miklos Szeredi <[email protected]>
- Re: Hibernation considerations
- Prev by Date: Re: [linux-pm] Re: Hibernation considerations
- Next by Date: Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
- Previous by thread: Re: [linux-pm] Re: Hibernation considerations
- Next by thread: Re: [linux-pm] Re: Hibernation considerations
- Index(es):