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.