> 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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
