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. ScottReceived on Mon Sep 01 2003 - 21:58:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:21 UTC