On Mar 20, 2010, at 3:49 PM, David Holland wrote: > On Sat, Mar 20, 2010 at 10:29:44PM +1030, Brett Lymn wrote: >> I have given up on suspending because my filesystems would be >> corrupted with monotonous regularity. The chances of a corruption >> seems to increase with the amount of disk activity happening on >> suspend. It seems like something is not being flushed (or not being >> marked as flushed) when the suspend happens. > > We don't support suspend-to-disk, right? So the contents of kernel > memory are supposed to be preserved in this suspend? Because if so, > unflushed buffers shouldn't matter. One would think. > > That suggests that something is flushing buffers to a device that's > suspended and it's throwing them away instead of rejecting them or > panicing.
Possibly.... > > Does stuffing a couple sync calls somewhere before it starts > suspending devices (wherever that is, I don't know) make the problems > go away? > > -- No -- I've had a sync call in my suspend script for years. More precisely, at the moment it's sync; sleep 1 to let things flush. No joy. Of course, rejecting them wouldn't seem to do any good; what's needed, I suspect, is for the device to queue them (as usual) but not fire up the disk when in suspending mode. --Steve Bellovin, http://www.cs.columbia.edu/~smb