Discussion:
Fiddling with auto snap frequency
Harry Putnam
2014-04-02 22:57:25 UTC
Permalink
I want to set auto-snap 'Frequent' runs to 10 min instead of (I think)
the default 15.

But after scanning thru a couple of google hits about how to fiddle
with the defaults.... I think I'd rather set my hair on fire.

Is it really so complicated a thing?

can anyone summarize what would need to be done to reset the frequency
of the 'Frequent' runs in specific zfs file systems.

I think the outcome I'm looking for is to pile up 5
"zfs-auto-snap_frequent" runs every hour instead of the current 3.
Kees Nuyt
2014-04-04 09:47:45 UTC
Permalink
Post by Harry Putnam
I want to set auto-snap 'Frequent' runs to 10 min instead of (I think)
the default 15.
But after scanning thru a couple of google hits about how to fiddle
with the defaults.... I think I'd rather set my hair on fire.
Is it really so complicated a thing?
can anyone summarize what would need to be done to reset the frequency
of the 'Frequent' runs in specific zfs file systems.
I think the outcome I'm looking for is to pile up 5
"zfs-auto-snap_frequent" runs every hour instead of the current 3.
Use svccfg to list/set properties for a service.

$ svccfg
svc:> select svc:/system/filesystem/zfs/auto-snapshot:frequent
svc:/system/filesystem/zfs/auto-snapshot:frequent> listprop zfs
zfs application
zfs/avoidscrub boolean false
zfs/backup astring none
zfs/backup-lock astring unlocked
zfs/backup-save-cmd astring "not set"
zfs/fs-name astring //
zfs/interval astring minutes
zfs/keep astring 4
zfs/label astring frequent
zfs/offset astring 0
zfs/period astring 15
zfs/snapshot-children boolean true
zfs/verbose boolean false
svc:/system/filesystem/zfs/auto-snapshot:frequent> exit
$
--
Groet, Cordialement, Pozdrawiam, Regards,

Kees Nuyt
Harry Putnam
2014-04-04 14:36:47 UTC
Permalink
Kees Nuyt <***@zonnet.nl> writes:

[...]
Post by Kees Nuyt
Post by Harry Putnam
I think the outcome I'm looking for is to pile up 5
"zfs-auto-snap_frequent" runs every hour instead of the current 3.
Use svccfg to list/set properties for a service.
$ svccfg
svc:> select svc:/system/filesystem/zfs/auto-snapshot:frequent
svc:/system/filesystem/zfs/auto-snapshot:frequent> listprop zfs
zfs application
zfs/avoidscrub boolean false
zfs/backup astring none
zfs/backup-lock astring unlocked
zfs/backup-save-cmd astring "not set"
zfs/fs-name astring //
zfs/interval astring minutes
zfs/keep astring 4
zfs/label astring frequent
zfs/offset astring 0
zfs/period astring 15
zfs/snapshot-children boolean true
zfs/verbose boolean false
svc:/system/filesystem/zfs/auto-snapshot:frequent> exit
$
Post by Harry Putnam
can anyone summarize what would need to be done to reset the frequency
of the 'Frequent' runs in specific zfs file systems.
+1 on what Kees wrote, and also - there are no per-dataset settings,
except enable-disable of autosnaps (completely or some schedules).
However, you can define new schedules (i.e. clone "frequent" with
different settings), just run
[...] snipped helpful tips
Post by Kees Nuyt
Post by Harry Putnam
I want to set auto-snap 'Frequent' runs to 10 min instead of (I think)
the default 15.
[...] snipped several excellent examples

Thank you both for the great input.

My idea was to set a faster frequent interval for one specific
filesystem and that not permanently. Or even 24/7.

I was hoping to use zfs snapshots as a quick and dirty versioning
system for limited times during scripting sessions. To keep a backlog
of versions of a script[s] in progress.

I'm thinking now, that for what I wanted to accomplish, monkeying with
the auto-snap feature is probably not the way to go, although Jim has
shown a way to do it. (along with some really helpful examples of
removing snaps)

Oh, and a side note that might throw a different light on things:
This is a single user machine running on a smallish home lan.

So,.....
I guess a hand rolled scheme for creating snaps (on top of auto-snap)
is more in order... better than messing with a system wide
feature. And something I can readily do.

Would there be any big downside (besides the obvious self maintenance
required) to running a perl script in the background, that creates
snapshots every N minutes, and starts rolling them over (oldest
first) after N or so are present?

This would be only for scripting sessions... so the script would only
be run at the start and stopped at the end.

The snaps would be totally removed periodically, when a new
script[s] was started.
Jim Klimov
2014-04-04 19:05:08 UTC
Permalink
Post by Harry Putnam
I guess a hand rolled scheme for creating snaps (on top of auto-snap)
is more in order... better than messing with a system wide
feature. And something I can readily do.
Would there be any big downside (besides the obvious self maintenance
required) to running a perl script in the background, that creates
snapshots every N minutes, and starts rolling them over (oldest
first) after N or so are present?
This would be only for scripting sessions... so the script would only
be run at the start and stopped at the end.
The snaps would be totally removed periodically, when a new
script[s] was started.
This is also quite an approach.
I am not ready to point at an URL at the moment, but I am certain
there were scripts in some blogs, mail-list archives or perhaps
even on the OI or illumos wikis, that do such rolling in logrotate
style (renumbering the snapshots so that .0 is most recent, etc.)

So yes, this approach also has "a right to be" :)

Also note that if your runtime user has proper permissions to the
dataset (see "zfs allow"), it can create snapshots by just running
:; mkdir $dataset/.zfs/snapshot/$snapname

Alas, removing them is not so easy ("zfs destroy" required), but
at least you can add simple logic into your script to i.e. create
a snapshot before it does something possibly disruptive, or after
completing a chunk of work, etc.

On a side note, question to the list: if an application queues
some asynchronous writes and then a request to make a zfs snapshot,
are there any guarantees that these writes would be committed
(without extra flush()es, sync or lockfs calls) and will become
part of that snapshot? Or is a snapshot a sync operation that may
become committed earlier than the data that was queued before it?

HTH, and thanks for clarifications,
//Jim
Nicholas George
2014-04-04 19:27:21 UTC
Permalink
Something like zsnapper, perhaps?

https://github.com/calmh/zsnapper
Post by Jim Klimov
Post by Harry Putnam
I guess a hand rolled scheme for creating snaps (on top of auto-snap)
is more in order... better than messing with a system wide
feature. And something I can readily do.
Would there be any big downside (besides the obvious self maintenance
required) to running a perl script in the background, that creates
snapshots every N minutes, and starts rolling them over (oldest
first) after N or so are present?
This would be only for scripting sessions... so the script would only
be run at the start and stopped at the end.
The snaps would be totally removed periodically, when a new
script[s] was started.
This is also quite an approach.
I am not ready to point at an URL at the moment, but I am certain
there were scripts in some blogs, mail-list archives or perhaps
even on the OI or illumos wikis, that do such rolling in logrotate
style (renumbering the snapshots so that .0 is most recent, etc.)
So yes, this approach also has "a right to be" :)
Also note that if your runtime user has proper permissions to the
dataset (see "zfs allow"), it can create snapshots by just running
:; mkdir $dataset/.zfs/snapshot/$snapname
Alas, removing them is not so easy ("zfs destroy" required), but
at least you can add simple logic into your script to i.e. create
a snapshot before it does something possibly disruptive, or after
completing a chunk of work, etc.
On a side note, question to the list: if an application queues
some asynchronous writes and then a request to make a zfs snapshot,
are there any guarantees that these writes would be committed
(without extra flush()es, sync or lockfs calls) and will become
part of that snapshot? Or is a snapshot a sync operation that may
become committed earlier than the data that was queued before it?
HTH, and thanks for clarifications,
//Jim
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/
22398343-302fa0bd
Modify Your Subscription: https://www.listbox.com/
member/?&
Powered by Listbox: http://www.listbox.com
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com
Harry Putnam
2014-04-04 23:29:14 UTC
Permalink
Post by Nicholas George
Something like zsnapper, perhaps?
https://github.com/calmh/zsnapper
Looks like it. Except I didn't feel too enlightened after looking over
the *ini. I suppose its fairly simple to run... and apparently runs
in the background some kind of way.

But, I was sort of looking forward to writing my own. Something to
keep my nearly non-existent perl skills from completely disappearing.

Plus, my needs are very low and primitive compared to most or many
solaris (of one kind or another) user. And particularly compared to
others on this newsgroup/maillist.

I'm thinking some simple little script that I run with 'snap.pl &' and
go to work on other scripting. Bring it back to foreground when I
stop, and ^c.

Though the ideas expressed in the zsnapper Readme do seem a good fit
for what I'm after. And so I may find my efforts lacking and go to
zsnapper after all.
Fabian Keil
2014-04-05 10:10:33 UTC
Permalink
Post by Harry Putnam
Post by Nicholas George
Something like zsnapper, perhaps?
https://github.com/calmh/zsnapper
Looks like it. Except I didn't feel too enlightened after looking over
the *ini. I suppose its fairly simple to run... and apparently runs
in the background some kind of way.
But, I was sort of looking forward to writing my own. Something to
keep my nearly non-existent perl skills from completely disappearing.
I wrote my own snapshot scripts, too, mostly because the
ones I knew about (a couple of years ago) didn't fit the
requirements.

When creating snapshots manually I use "snap" which is a trivial
shell function that calls "zogftw snapshot" and I use zsd
(written in Perl) to trim away snapshots above a given limit:
http://www.fabiankeil.de/gehacktes/zogftw/
http://www.fabiankeil.de/gehacktes/zsd/

Parts of zogftw are only expected to work on FreeBSD-based
systems, but its snapshot code and zsd should work on other
platforms as well.

The "list-snapshots-faster" options are probably nops there,
though, as I believe Pawel's speed improvements for FreeBSD
still haven't been imported to illumos.

Fabian
--
2014-04-12/13: Protest against mass surveillance in Cologne, Germany
http://cologne.stopwatchingus.info/demo-12-april/en.html
Kees Nuyt
2014-04-05 09:52:06 UTC
Permalink
Post by Harry Putnam
Thank you both for the great input.
My idea was to set a faster frequent interval for one specific
filesystem and that not permanently. Or even 24/7.
I was hoping to use zfs snapshots as a quick and dirty versioning
system for limited times during scripting sessions. To keep a backlog
of versions of a script[s] in progress.
I would use a simple source management system for that, like
fossil ( http://www.fossil-scm.org/ )

A recent version, compiled for Solaris x86 is available at
http://knuyt.home.xs4all.nl/fossil/index.html
--
Groet, Cordialement, Pozdrawiam, Regards,

Kees Nuyt
Jim Klimov
2014-04-04 10:54:09 UTC
Permalink
Post by Harry Putnam
can anyone summarize what would need to be done to reset the frequency
of the 'Frequent' runs in specific zfs file systems.
+1 on what Kees wrote, and also - there are no per-dataset settings,
except enable-disable of autosnaps (completely or some schedules).
However, you can define new schedules (i.e. clone "frequent" with
different settings), just run
:; svccfg export zfs/auto-snapshot > /tmp/zas.xml
to produce a copy of the current service definition, open with a
text editor and copy the instance block which you want to use as
a template for your other schedule (i.e. "mynewsched"). Then just:
:; svccfg import /tmp/zas.xml
:; svcadm refresh zfs/auto-snapshot:mynewsched
:; svcadm enable zfs/auto-snapshot:mynewsched

Also you might want to only enable this schedule for particular
datasets, i.e.:
:; zfs set com.sun:auto-snapshot:mynewsched=false rpool
:; zfs set com.sun:auto-snapshot:mynewsched=true rpool/export/home

I disclaim that I haven't actually tried this, but am quite sure
that it should work... close to these examples ;)

HTH,
//Jim Klimov
Jim Klimov
2014-04-04 11:03:50 UTC
Permalink
Post by Harry Putnam
I want to set auto-snap 'Frequent' runs to 10 min instead of (I think)
the default 15.
Also note that snapshotting system datasets like rpool/swap and
rpool/dump is nearly useless, and may be even "toxic" since the
snapshots would reserve disk space from your rpool (if there
are any allocated blocks in those volumes). So you might want to
:; zfs set com.sun:auto-snapshot=false rpool/dump
:; zfs set com.sun:auto-snapshot=false rpool/swap

...and verify that there are no snapshots of these already:
:; zfs list -tall -r rpool/dump rpool/swap

... and if there are ... well ... that's not for long:
:; zfs list -Honame -tsnapshot -r rpool/dump rpool/swap | \
while read Z; do zfs destroy $Z & done; wait; sync

Note that this deletes all snapshots, which is what you'd want
for these datasets. For most others you'd want to filter out
just the automatic ones, i.e. something resembling this:
:; zfs list -Honame -tsnapshot -r rpool/export | \
egrep 'zfs-auto-snap.*2014-02-08' | \
while read Z; do zfs destroy $Z & done; wait; sync

HTH,
//Jim Klimov
Loading...