Messages in this thread |  | | Date | Sat, 9 Feb 2013 18:49:10 +0100 | From | Pavel Machek <> | Subject | Re: [fuse-devel] [PATCH] fuse: make fuse daemon frozen along with kernel threads |
| |
Hi!
> > The only way to *reliably* freeze fuse filesystems is to let it freeze > > even if there are outstanding requests. But that's the hardest to > > implement, because then it needs to allow freezing of tasks waiting on > > i_mutex, for example, which is currently not possible. But this is > > the only way I see that would not have unsolvable corner cases that > > prop up at the worst moment. > > > > And yes, it would be prudent to wait some time for pending requests > > to finish before freezing. But it's not a requirement, things > > *should* work without that: suspending a machine is just like a very > > long pause by the CPU, as long as no hardware is involved. And with > > fuse filesystems there is no hardware involved directly by definition. > > > > But I'm open to ideas and at this stage I think even patches that > > improve the situation for the majority of the cases would be > > acceptable, since this is turning out to be a major problem for a lot > > of people. > > For shutdown in userspace there is the sendsigs.omit.d/ to avoid the > problem of halting/killing processes of the fuse filesystems (or other > services) prematurely. I guess something similar needs to be done for > freeze. The fuse filesystem has to tell the kernel what is up.
Would it be feasible to create some kind of fuse-stop-script.sh, and run it before suspend (from userspace)? It should be pretty similar to sendsigs.omit.d/ mechanism AFAICT.
I'm sorry, freezer is not too suitable for fuse.
(BTW: for suspend, we may be able to improve it so that it is possible to remove freezer from it. For hibernation, it would be very hard.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
|  |