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