XigmaNAS

NAS4Free 9.2.0.1 (revision 943) x64-embedded
ALASKA A M I Intel(R) Pentium(R) CPU G3220 @ 3.00GHz 8960MiB RAM


UPDATE (23 Nov): See post viewtopic.php?p=45696#p45696 for the root/origin/cause of this problem.

Description:
The title explains the problem. I have rolling snapshots set up as in the screenshot below, however no snapshots are being deleted. I do not have any
clones mounted.




But clearly, these rules are not being followed. I have already deleted some older ones manually as well. I have not attached a screener of the "Jail" directory, but the rules are not being adhered to there either.




I saw a related open ticket for a bug in an earlier version of NAS4Free here:http://sourceforge.net/p/nas4free/bugs/140/


Does anyone have any ideas?


Thanks!

Hi,

I have seen this too and only when changing the snapshot frequency to a lower value which is less than the number of snapshots. E.g. set for 90 days and then after say 100 days change this to 30 days. It will not delete snapshots older than 30 days and leaves them in the list but it will then start performing the rolling 30 day retention from the point of change going forwards.

My version is lightly newer than yours too:
9.2.0.1 - Shigawire (revision 972)
x64-embedded on Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz with 32472MiB RAM

I hope that helps you a little, and I too think this is a bug.

Mike

Thanks for that.

I have updated to revision 972 and manually deleted all snapshots outside the specified parameters. Will report back in a few days with results.

Updating did not solve my issue...maybe I#ll try destroying all snapshots and let it start fresh.

I have the same issue, however believe the issue is related to time. When i look in the system log, the snapshot name that is created and the one that is trying to be destroyed don't have the same timestamp.

Nov 20 03:00:00 nas4free Auto Snapshot: /sbin/zfs destroy -r ZFS@auto-20141020-040000
Nov 20 03:00:00 nas4free Auto Snapshot: /sbin/zfs snapshot -r ZFS@auto-20141120-030000

Is there a timezone problem? why isn't the destroy at 030000?

Anybody know how to solve this?

Ok, I also checked my log (too bad I hadn't thought to do that before) and this is exactly my problem. Oddly, for one of my smaller datasets it works fine, but for my main dataset it does exactly this -- the destroy command calls for a snapshot with a filename that is one hour ahead of what it should be, so that nothing is deleted and the datasets accumulate infinitely without manual intervention.
This seems to be a bug in the code.

N4FJerry, thanks for your post. What are your timezone settings, by chance? I doubt that is the source of the problem, but maybe it's worth looking into.

I am on Europe/London with time set to update automatically via NTP.

Syncing with pool.ntp.org, America/New York, and the time looks right from the UI. I believe the issue is the math functions being applied to the "date" function and us recenetly crossing the daylight saving boundary. The code in /usr/local/sbin/autosnapshot calculates the name of the file based on the number of seconds from now, and it was an hour later 30 days ago...

# oldest snapshot name
lifetimesec=`/bin/expr $NOW - ${_lifetimesec}`
delname=`/bin/date -j -f "%s" $lifetimesec "+${_name}"`
if [ -z $delname ]; then continue; fi;
delsnapshot="${_path}@${delname}"

seems like the deletes will be off twice a year for whatever the retention period is.

You were right. This has now corrected itself a month after the time change over here in Britain. Good to know that any time the clocks change it will require manual intervention to destroy old snapshots for a while.

Does anyone know how to log this as an official bug?

Thank you for reporting.
It's a difficult for me. Japan time have no summer time (DST).
It seems the script should not calc on current time.

How about this:
Before: After: Thanks,
--
Daisuke Aoyama

Hi Daisuke,

Two things about autosnapshot:

1) whatever process creates /var/etc/autosnapshot seems to have a typo. Here's mine, with a 14 day retention:
daily zpool auto-%Y%m%d-%H0000 true * * 2000 0000 2w 1296000

That last number should be 1209600, which is causing the script to leave snapshots for an extra day. Not a big problem really, just thought I'd mention it.

2) a feature request: Solaris and Linux both use the ZFS property com.sun:auto-snapshot=false to specify that you don't want a dataset/volume to be autosnapshotted. If you ever feel like adding such a feature, it would be nice to use the same standard. Also not a big deal, the only thing I want to skip are volumes used as swap volumes for VMs, so they don't use much space anyway!

Thanks,
Andy