So, for a second time a power outage ran down my UPS and the Qube had 
its power terminated rudely.

This happened once before, and I had to run fsck_ffs manually from 
console on  /dev/rwd0g (/tmp) to get the Qube to boot.  It found and 
cleared  a couple errors that I didn't note, a handful of sectors that 
couldn't be read, salvaged the free blk counts and summary info and 
"bit maps" and marked the filesystem clean.

This is Michigan!  and we have t-storms, and I don't really want to go 
thru this every time there's a power outage that lasts long enough to 
drain my UPS battery.  The daemons running are sshd, postfix, plus 
occasionally icecast and ices.  Since /tmp is getting trashed, I'm 
assuming it's something related to icecast temp files but I can't prove 
that.  I've power cycled it rudely occasionally months ago without 
icecast running with no problems noticed, but I do try not to do that.

- can I set anything to run at a cold boot that would help automate 
this cleanup process?

-I have a few disk sectors that cannot be read (uncorrectable data 
error, anyway)- 756-768 inclusive.  These are the same ones as last 
time. I guess they really are bad- but then why are they not mapped out 
after the last fsck_ffs cleared up issues?  Or did they get mapped out, 
but the bad reset trashed the table?   I'm not sure how the BSD FS 
handles this stuff; I have in the past dealt with failing drives by 
mapping out bad sectors by hand every week, or parking a big fie on 
them  and then leaving them alone :) but that was MFM media days... 
what's the big picture in how stuff like this gets handled with NetBSD 
(1.6.1 if it matters)?  This is a rather new, large HD- I rather want 
it to be in good shape.

-since its just /tmp can I (re)format that partition and get these 
blocks mapped out permanently?  Other solutions?

Thanks for help,

Brian