Loading Profile...
MacFUSE force ejects volumes if userland process is unresponsive
I wonder if you can come up with a solution to this on your side.
I just had many heavyweight programs open and my machine started swapping heavily for about half a minute. It was so severe that iTunes playback started stuttering, something I see very rarely.
During that time, it seems the ExpanDrive userland process was starved too and thus couldn't respond to MacFUSE, causing MacFUSE to force eject the volume:
22.07.08 22.07 09:13:53 kernel kern Debug MacFUSE: force ejecting (no response from user space 5)
Now the volume is still visible on the desktop and in the mount table:
ExpanDrive on /Volumes/fL devel-rhel5 (fusefs, local, nodev, nosuid, synchronous, mounted by liyanage)
But if I try to open folders or save open documents to it, it fails with an error message. I *guess* but am not 100% sure that this is caused by/related to the kernel message above.
1.) I wonder if you can do something about it on your side, for example set some API option so MacFUSE gives the userland part of ExpanDrive more time to respond before force ejecting.
2.) If that is not possbile, it would be nice if ExpanDrive would notice the disconnect and, in order of preference, 1.) try to reconnect or 2.) eject the volume (icon and mount table entry) and present an error message. Something like a health/communication check between ExpanDrive and MacFUSE would be nice in this case, to check if the whole system is in fact in the state ExpanDrive assumes it to be.
This actually leads me to a larger issue with ExpanDrive:
I consider at least the removal of the icon and mount table entry to be essential, because this "disconnect" between the actual system state and the UI state is very annoying for the user. I have seen it in other situations with ExpanDrive (not just MacFUSE <-> userland problems, but also after host <-> host SSH connection breakdown) and I consider it one of the biggest problems than can happen in ExpanDrive.
Frankly, a connection breakdown with visibly force ejected volumes and a big fat error message would be *way*, way better than this visual state that *suggests* to me that everything is OK but does not reflect reality. It would be great if you could enhance this part of the experience so that I know 100% that if I see the icon, the connection is up and I will be able to work.
I just had many heavyweight programs open and my machine started swapping heavily for about half a minute. It was so severe that iTunes playback started stuttering, something I see very rarely.
During that time, it seems the ExpanDrive userland process was starved too and thus couldn't respond to MacFUSE, causing MacFUSE to force eject the volume:
22.07.08 22.07 09:13:53 kernel kern Debug MacFUSE: force ejecting (no response from user space 5)
Now the volume is still visible on the desktop and in the mount table:
ExpanDrive on /Volumes/fL devel-rhel5 (fusefs, local, nodev, nosuid, synchronous, mounted by liyanage)
But if I try to open folders or save open documents to it, it fails with an error message. I *guess* but am not 100% sure that this is caused by/related to the kernel message above.
1.) I wonder if you can do something about it on your side, for example set some API option so MacFUSE gives the userland part of ExpanDrive more time to respond before force ejecting.
2.) If that is not possbile, it would be nice if ExpanDrive would notice the disconnect and, in order of preference, 1.) try to reconnect or 2.) eject the volume (icon and mount table entry) and present an error message. Something like a health/communication check between ExpanDrive and MacFUSE would be nice in this case, to check if the whole system is in fact in the state ExpanDrive assumes it to be.
This actually leads me to a larger issue with ExpanDrive:
I consider at least the removal of the icon and mount table entry to be essential, because this "disconnect" between the actual system state and the UI state is very annoying for the user. I have seen it in other situations with ExpanDrive (not just MacFUSE <-> userland problems, but also after host <-> host SSH connection breakdown) and I consider it one of the biggest problems than can happen in ExpanDrive.
Frankly, a connection breakdown with visibly force ejected volumes and a big fat error message would be *way*, way better than this visual state that *suggests* to me that everything is OK but does not reflect reality. It would be great if you could enhance this part of the experience so that I know 100% that if I see the icon, the connection is up and I will be able to work.
I’m ejected
1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
-
Inappropriate?If you eject from the drive manager (Command-E or right-click->"eject"), ExpanDrive does what you're asking. I suppose we should be be more forthright about the fact that "eject" is actually force-eject.
MacFuse has a daemon timeout that kicks in after 60 seconds with no response from userland, but it doesn't always properly unmount. We can't disable it entirely, or else your whole system would become unresponsive in the case where MacFuse is starved for data. Perhaps there is a bug with ExpanDrive in that it doesn't obey the MacFuse force-eject, and we'll look into that. For the time being, the manual force-eject from the drive manager should suffice.1 Comment
Add a comment
This solves the problem
-
I was aware that manually ejecting works, that plus a remount is what I did.
My wish is really more that ExpanDrive should have tighter integration between the low-level state and the GUI, thus the suggestion for a health check or something like that. It is very annoying when the GUI suggests that everything is OK when in fact it isn't.
This issue goes a bit beyond the specific problem at hand.
