deleted. I guess we should not allow users to do this, eh?

I'm way to frustrated at this point. Back to using master ...

When creating a pre-reserve, new -n option to specify a name for the
reservation, defaults to "default". All other operations require an
-n option to avoid messing with the wrong reservation. You are not allowed
to reuse a reservation name in a project, of course. Priorities are
probably more important now, we might want to change the default from 0 to
some thing higher, and change all the current priorities.

For bookkeeping, the nodes table now has a reservation_name slot that is
set with the reserved_pid. This allows us to revoke the nodes associated
with a specific reservation. Bonus feature is that when setting the
reserved_pid via the web interface, we leave the reservation_name null, so
those won't ever be revoked by the prereserve command line tool.

New feature; when revoking a pre-reserve, we now look to see if nodes being
revoked are free and can be assigned to other pre-reserves. We used to not
do anything, and so had to wait until that node was allocated and released
later, to see if it could move into a pre-reserve.

Also a change required by node specific reservations; when we free a node,
need to make sure we actually use that node, so have to cycle through all
reservations in priority order until it can used. We did not need to do
this before.

statewait) are not killed by the stateful firewall.

accounts/passwords). Thanks to Mike Blodgett for cluing us in to this and
providing the configuration he was using. This will run from cron a couple
of times a day. The setup is not quite fully automated yet, need to create
/usr/local/etc/medusa/{wordlist.txt,userlist.txt} by hand, as well as the
crontab entry.

We are scanning all local nodes (including VMs) as well as any allocated IP
addresses in address pools.

Minor tweaks so that ipfw/dummynet sets up properly. Allow dynamic
config (delay_setup) to accept a BW value up to 1Gb (was 100Mb).
Somewhat dubious: if the incoming interface speed matches the desired
shaping BW, set the BW to unlimited on the pipe (since the interface
is already throttling for us).

BEWARE! The fidelity of shaping at over 1Gb (e.g., adding delay to a
10Gb link) is awful. Even a 10Gb pipe with no delay or loss only achieved
about 7Gb/sec max. The delay node code needs serious work!

Really big mess for the pc3000s nowadays.

fullname field in the DB.

Allowing oversubscription can push the current_load of a pnode
over its max_load, which causes us to try to take the square
root of a negative number. So, add an explicit check for that case.

Consists of just a command line option right now!

Currently this is done using the -E (erase) option to zapdisk to
erase a partition or the entire disk.

We run zapdisk before starting a frisbee load. Ultimately, I want
TRIM support in frisbee proper (to erase rather than skip or zero
free blocks), but erasing the entire disk might be a better option
anyway (frisbee itself will benefit from the TRIMed disk).

Notes:

We only trim the disk when a node is in reloading. Didn't want to take
a chance on having a user reload a partition on their disk and wind up
getting the entire disk erased. That should not happen, but I didn't
want to think through all the possibilities right now.

Only works on FreeBSD right now. Linux MFS will still need to be modified.
Just didn't want to track down how Linux does block erase right now.

The clientside here is different than what is used on the Moonshots.
On the Linux-based Moonshot MFS, we TRIM in slicefix by running fstrim
on the root FS we just layed down. This used to be a good alternative
back when the root FS occupied the entire disk, but now it won't work
as well as we will only trim blocks from the first 6GB. Need to switch
this over to the zapdisk (or frisbee) based TRIM.

The server infrastructure on the Moonshots is the same: tmcc passes a
TRIM=1 flags in "loadinfo" when the disk should be trimmed. So when to
TRIM is based on the time since the last TRIM, and can now be specified
site-wide, per-nodetype, or per-node.

Currently, slicefix (x86 or ARM) doesn't do anything to the FS layed
down to ensure that TRIM is done during the lifetime of the FS. Both
FreeBSD and Linux have such options that can be set when the FS is
created or added with tunefs. We need to think about this for mkextrafs
and local blockstores as well.

Make the interval between TRIM operations a per nodetype (or per node)
attribute instead of a global site variable. The sitevar will still be
used to turn TRIM on or off globally.

The latter causes on/off/cycle operations to return a generic error
(though the operations do work!)

	boss> wap perl prereserve lbsbox pcxxx pcyyy ...

Overall pre-reserve handling is unchanged; if there is a another higher
priority type pre-reserve, it will be filled first. Moral, be sure to think
about the priority argument, which you had to do anyway.

need node_reservations for, well, node_reservations.

is in the Cloudlab or aptguest projects.

ptopgen that adds wiretypes to the ptop file.

to use this code.