On Tue, Mar 20, 2007 at 12:14:43PM -0300, Henrique de Moraes Holschuh wrote: > > Maybe, but then the suspend mail have to fail if there are processes > > that are keeping the filesystem from being unmounted. Or the > > Yes. But this is standard functionality on the suspend path, anyway. The problem with this is that some users will hit the suspend button, close the lid, put the laptop into their laptop bag, and then immediately head off to the next conference talk (or whatever). If the suspend is going to fail, they might not notice, and they might not swap out the bay in any case. > > processes hanging out on the hard drive or CD-ROM could get all of > > their file descriptors revoked on resume, I suppose, if the bay has > > been switched out..... > > Urk. It is better to either fail the suspend, or to not power down the bay. > Or to give the user a choice of which he'd rather happen. Hmm... Yeah, I think it needs to be configurable. In many cases the right thing to do is for the user to promise not to swap out bay, and in the exception case where they do, all of the processes that have files open on that bay will have to get their fd's revoked. We can try to make it less likely for there to be data loss, like asking filesystems that support write_super_lockfs() to quiesce the filesystem before the suspend, but the assumption should be that users aren't supposed to be swapping out the bay if they request the suspend code not to disconnect the filesystem. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
