swapon vs savecore dilemma

Scott Long scottl at freebsd.org
Mon Sep 1 23:58:56 PDT 2003


Doug Barton wrote:
> On Tue, 2 Sep 2003, Poul-Henning Kamp wrote:
> 
> 
>>Hmm, that was an unfortunate side effect.
> 
> 
> Heh, well, stuff happens. I think your idea of opening swap exclusive is
> probably a good one, but it will require some gymnastics to accomodate
> it. One thing that'd really help is an option to savecore that tells us
> if there is a dump to deal with or not. If I had that, we could do
> something like this in /etc/rc.d/savecore
> 
> if there is no dump
> 	exit
> else
> 	does fsck -p of the fs to write the dump to succeed?
> 		mount it rw
> 		write the dump
> 		clear the dump
> 		exit
> 	else
> 		does try fsck -y of the fs without swap succeed?
> 			mount, write, clear, exit
> 		else
> 			???
> 
> At the ??? point I'm not sure how best to proceed, since if we swapon to
> the same partition with the dump, it's likely to corrupt the dump, yes?
> On the other hand, we're doing swapon before savecore now, so I guess
> I'm curious about how dangerous this really is.
> 
> Probably the right thing to do is to swapon, fsck -y, and if it succeeds
> then swapoff, and try writing the dump anyway. I just want to be
> sure before we start re-writing rc.d/savecore.
> 
> So, the first question is does the pseudocode above look reasonable, and
> the second question is what's the likelihood of getting an option to
> savecore to detect a dump to play with?
> 
> Doug
> 

I still think that the real problem is in running swapon before
savecore.  In 99% of the cases out there, RAM scales with storage,
so I really can't imaging fsck needing to swap, and certainly not
in it's 'preen-before-background' mode.

Scott



More information about the freebsd-current mailing list