freebsd-skq/usr.sbin/swapinfo
Bruce Evans 99fb10656e Don't follow a null pointer for the reporting error if kvm_openfiles() fails.
Don't ever pretend that the program is named "." and has no args.
1994-11-14 07:54:06 +00:00
..
devname.c swapinfo(1) command from 1.1.5. This version has been modified to work 1994-08-12 01:49:30 +00:00
Makefile From: John Hay <jhay@mikom.csir.co.za> 1994-10-26 14:49:07 +00:00
README swapinfo(1) command from 1.1.5. This version has been modified to work 1994-08-12 01:49:30 +00:00
swapinfo.1 swapinfo(1) command from 1.1.5. This version has been modified to work 1994-08-12 01:49:30 +00:00
swapinfo.c Don't follow a null pointer for the reporting error if kvm_openfiles() fails. 1994-11-14 07:54:06 +00:00

swapinfo
========

Swapinfo is designed to provide some information to the user about the
state of the swap space on the system.  I've written it based on a 
brief (!) perusal of the VM code in 386BSD.  I could be pretty confused
about how it all fits together, and perhaps this is totally bogus.
It seems to work for me, though.

How it works:

During startup, the system traverses the list of configured swap partitions,
and determines the size of the various partitions.  As each new partition
is added for swapping (via swapon), the free space on that disk is added
to a linked list of free space.  Adjacent areas are coalesced to form
larger areas.  The swapping algorithm seems to take the first free section
that it finds [?].

Swapinfo reads in the list of configured swap partitions from the /dev/kmem,
to determine the size of the partitions.  It then traverses the list
of free space, figuring up how much is still available and how much
has therefore been used.  Things get a little hairy in that the swap space
is divided amongst the configured swap partitions so that the first
4096 blocks of swap go on the first swap partition, the second 4096 on
the second swap partition, and so on.  This works out to be a fairly
simple bit of code, though.

More caveats:

This works on my system.  Your milage may vary.  Since I'm reading /dev/kmem
to follow a linked list, the program could easily get lost looking for
some free space if anything got changed between reads of /dev/kmem.
If you get occasional inconsistant results, ignore 'em.

Feel free to send bug reports, flames, etc., to:

Kevin Lahey
kml@rokkaku.atl.ga.us