Re: panic: ffs_valloc: dup alloc

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

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