FATAL: trying to delete zfs pool or filesystem? WTF? about zfsnap HOT 16 CLOSED

Looks like similar output in the daily run output:

Scrubbing of zfs pools:
   starting scrub of pool 'pool0':
      consult 'zpool status pool0' for the result
   skipping scrubbing of pool 'zroot':
      last scrubbing is 7 days ago, threshold is set to 11 days
/sbin/zfs snapshot -r pool0/home@daily-2014-02-22_03.48.08--1w ... DONE
/sbin/zfs snapshot -r zroot@daily-2014-02-22_03.48.08--1w ... DONE
NOTE: No action will be performed on 'pool0@daily-2014-02-14_04.15.58--1w'. Scrub is running on pool.
FATAL: trying to delete zfs pool or filesystem? WTF?
  This is bug, we definitely don't want that.
  Please report it to https://github.com/graudeejs/zfSnap/issues
  Don't panic, nothing was deleted :)

from zfsnap.

Which zfSnap version is that? And what os are you running?

from zfsnap.

Sorry, those are obvious questions that I should have answered originally.

I'm using zfSnap 1.10.0 from the FreeBSD package system. Running on FreeBSD 10.0-RELEASE.

from zfsnap.

I just got exact same thing:

FATAL: trying to delete zfs pool or filesystem? WTF?
  This is bug, we definitely don't want that.
  Please report it to https://github.com/graudeejs/zfSnap/issues
  Don't panic, nothing was deleted :)

I wonder if its due to the pool being currently scrubbed? Although i daily an hourly snapshot using zfSnap and I have had a scrub run every sunday without interference between the operations.

from zfsnap.

@GusBricker Scrubbing shouldn't impact this. Which version of zfsnap are you running, and on which OS?

from zfsnap.

1.11.1
I'm looking thru the code currently. I wonder if its because I have an identical pool mounted with a different name? I will do some debugging and report back soon.

from zfsnap.

I think I have found the problem. Its actually two problems from what I can see. First let me explain my setup which has caused this to occur. Currently I have two pools plugged in: Primary and Slave2. Slave2 is just an exact copy of primary at some instant in time (happens to be a few hours ago). Primary has an hourly snapshot being created with a ttl of 1 day.

Problem 1:
Line 180 of zfSnap (this is referencing v1.11.1 code):

if echo $i | grep -q -e '@'; then

I think that should be $* instead of $i. As $* is the snapshot which will be destroyed.

Problem 2:
There needs to be a way to tell zfSnap to only look at a particular dataset. Currently it is trying to manage snapshots for both slave2 and primary. By the looks of it, zfSnap deletes the snapshots oldest to newest. I have an old snapshot on slave2 which doesn't exists on primary hence why its getting this error. For some reason I was under the impression you could pass in the dataset you wanted zfSnap to manage snapshots for, however I can't see this in the code anywhere?

from zfsnap.

@GusBricker There have been /a lot/ of changes and bugfixes to zfsnap since the 1.x code, and I believe that entire section has been rewritten.

As for your feature request: I havn't looked at the 1.x code in awhile (and I don't have the time at the moment), but I know that zfsnap 2.x can properly filter to any dataset.

Even though zfsnap 2 isn't released yet (I've been meaning to for months now), it is pretty well tested and I'm aware of only one bug (and it's portability related). Would you be adverse to giving that a try and see if fixes your bug and gives you the scanning flexibility you want? The syntax is a bit different, but is much more flexible.

---Alex

from zfsnap.

Yes I can try version 2. One question before I try it, is the snapshot naming still the same (ie will zfSnap 2 delete all my 1.11.1 created snapshots)?

from zfsnap.

@GusBricker The naming convention for snapshots is unchanged. The /only/ difference, is that the old 1.x regex's were slightly too broad, and would have matched some snapshots that zfSnap would not have created, but could (in an incredibly unlikely scenario) have been named manually by a sysadmin with a twisted sense of humor.

So, you should have no problems.

---Alex

from zfsnap.

Though, as with anything, I recommend using the -n (dry-run) option as you get used to the new syntax.

from zfsnap.

Ok, I will try it out tomorrow afternoon, definitely with dry-run enabled.

from zfsnap.

I just implemented v2.0.0beta1 on our system and tried it out. It all seems to work. With my two pools connected (primary and slave2), I can let zfsnap cleanup snapshots on primary and it no longer affects slave2's snapshots. :)

Nice work.

from zfsnap.

@GusBricker Excellent. I'm glad it resolved your problems. :-)

---Alex

from zfsnap.

Whoops. Just realized you didn't originally open the ticket...

@rcsheets Is upgrading to the latest beta an option for you?

---Alex

from zfsnap.

Closing, as this seems to be resolved in the 2.x codebase.

---Alex

from zfsnap.