Subject: Re: swapctl -a doesn't do load-balancing; whyzzat?
To: None <greywolf@starwolf.com>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-kern
Date: 09/04/2000 09:23:29
Date: Sat, 2 Sep 2000 16:06:41 -0700 (PDT)
From: Greywolf <greywolf@starwolf.com>
Message-ID: <Pine.NEB.4.21.0009021604390.8927-100000@mage.starwolf.com>
| Is there something in the works for this or have I missed something?
I had the exact opposite experience - I was making a CD image, and
mkhybrid (which I chose) was eating VM as if it was all virtual or something,
and I had great fears that (after an hour or so of elapsed time) was
about to run out, and give up - which I didn't want.
The only place I had excess space on the system concerned was via NFS, so
I made myself a nice huge swap file out there, and enabled swapping.
Almost before I could think, the system (which was paging its little head off
of course - that's why everything was taking so long in the first place)
had started moving all kinds of stuff from the local disc out to NFS
swapping, which didn't improve its performance of course... (And yes, I
had managed to forget to set the swap priority, so the NFS swap space
had defaulted to being equivalent to the local disc).
I changed the priorities around, and things started to migrate back to
swapping off the local drive again - but I never managed to get it all the
way back - not that that mattered all that much, the system needed a
reboot soon after anyway, the point of this was to make a (archival, and
ordinary) backup prior to doing some filesystem rebuilding. But, of
course, as things worked out, the NFS swap wasn't actually needed anyway,
I think I would have still had 5MB or so of the local drive swap space
free ...
kre
ps: mkhybrid needed all that VM because of an absurdly large number of
files being written to the CD, the filesystem rebuilding was to make a
filesystem, with a higher than default inode::block ratio, as with the
default it had run out of inodes, and still had plenty of free blocks -
zillions of very small files.