sbin/hammer: Don't ioctl(SET_PFS) before attempt to destroy PFS
This is part 1/2 of what's mentioned in below post.
Two ondisk PFS data (deleted PFS followed by undeleted PFS data) will
still appear with this commit, like what's mentioned in below post.
(This comes from HAMMER's flushing mechanism, so it's basically a bad
idea to try to fix it unless it's possible without touching core part
of HAMMER's flusher code, provided that this extra ondisk PFS data
does nothing bad. This may be fixed in the future as part 2/2 patch.)
http://lists.dragonflybsd.org/pipermail/users/2016-August/313004.html
This part 1/2 patch alone is still effective even without part 2/2.
If the PFS is successfully destroyed, the ondisk PFS data written by
ioctl(HAMMERIOC_SET_PSEUDOFS) prior to destroying (which is the code
removed by this commit) gets shadowed by the one with deleted flag,
so no one is to (or no one needs to) access that.
If failed to destroy the PFS, the original ondisk PFS data is restored
using a copy of the original data, so ioctl(HAMMERIOC_SET_PSEUDOFS)
prior to destroying is still unnecessary. Also see
750beaef.
Restoring part by
750beaef could be removed too since the PFS is not
downgraded or updated anymore.