It seems I am about to end up on the same conclusion as before (just failing to document them back then). So the block device is removed as intended (del_gendisk is called). Just from there it seems to be no way to sanely handle it. I suspect the udisk assisted mount under /media also creates a watch (fsnotify/inotify) that will try to do an unmount when the block device goes away. If anything is using the fs at that point, things get screwed. While somehow the entries in /proc/mounts (and probably /etc/mtab as well) go away, the fs instance remains somewhere dangling and causes a new mount to fail. For manual mounts its even worse because there is no udev rule that would even try to unmount when a remove event takes place.
And despite the scary aspect from getting those pop-ups about the mount failure after suspend, it probably is safer to immediately see there is a problem than to have the fs in use be some application and then only getting unexpected IO errors. There is a manual workaround there (which also has its own dangers): the mmc core accepts a parameter removable (which is also settable through sysfs). If that is set to 0, then the card is really only suspended. Anybody replacing the card while in suspend will be in pain though... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/913860 Title: Suepend/resume causes problems with mounted and active mmcblk device To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/913860/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
