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
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
