On Tue, 20 Mar 2007, Theodore Tso wrote: > 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. Well, it needs to be *optional* anyway. But the above isn't the reason, though. Suspend *can* already fail, and anyone who acts like the above deserves to have to replace their laptop HD more often than those who actually wait the laptop to be suspended before they toss it into the bag :-) > > > 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. Agreed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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
