zfs discuss - Nov 2009 - [Fwd: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion in snv 128]

Hi all,

Just forwarding Niall''s heads-up message about the impending removal of
the existing zfs-auto-snapshot implementation in nv_128

I''ve not been involved in the rewrite, but what I''ve read
about the new
code, it''ll be a lot more efficient than the old ksh-based code, and
will fix many of the problems with the old solution.

The new code currently lacks support for the ''zfs/backup''
functionality
- which allowed you to specify a command to tell the service to generate
incremental or full send streams at each time interval, along with a
commandline to process that stream (sshing to a remote server and doing
a zfs recv, for example)

If you do use that functionality, it''d be good to drop a mail to the
thread[1] on the zfs-auto-snapshot alias.


It''s been a wild ride, but my work on zfs-auto-snapshot is done I
think :-)

	cheers,
			tim

[1]
http://mail.opensolaris.org/pipermail/zfs-auto-snapshot/2009-November/thread.html#199

-------- Forwarded Message --------
From: Niall Power <Niall.Power at Sun.COM>
To: zfs-auto-snapshot at opensolaris.org
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
in	snv 128
Date: Mon, 16 Nov 2009 18:26:28 +1100

This is a heads up for user of Tim''s zfs-auto-snapshot auto snapshot 
service currently delivered
in Solaris Nevada and OpenSolaris. As of build 128 the zfs-auto-snapshot 
scripts are being replaced
by a rewritten daemon (time-sliderd).
Time-sliderd will continue to support the existing SMF 
auto-snapshot:<schedule> service instances
as it''s configuration mechanism so for most users there should be no 
significant differences noticeable.
Some of the options will no longer be supported however since they are 
either obsolete or too
specifically tied to the zfs-auto-snapshot implementation to make them 
portable.

Stuff that will work:
- Default out of the box schedules (frequent, hourly, daily, weekly, 
monthly)
- Custom schedules

SMF properties that will be supported:
- interval
- period
- keep

SMF properties that won''t be supported
- "offset" The time-slider daemon schedules snapshots based on
relative
   times rather that absolute times which makes it more suitable for systems
   that do not have constant 24/7 uptime so this feature isn''t so
relevant
   anymore (it only got implemented recently in zfs-auto-snapshot also)

- "label" Dropping it allows naming shemes to be simplified and
   enforces uniqueness when SMF tries to import an auto-snapshot instance

- backup/backup-save-cmd/backup-lock
  We plan to implement an rsync based backup mechanism that allows backups
  to be browsed like a proper filesystem instead of having binary 
snapshot blobs
  that are explicitly classified as unstable/volatile by zfs(1)

For those who want to use time-slider without going through the GUI, simply
enable/configure (or create) the auto-snapshot instances you need then 
enable
the time-slider SMF service. time-slider will pick up the enabled 
auto-snapshot
instances and schedule snapshots for them.

For folks who prefer to continue using zfs-auto-snapshot, you will need to
remove SUNWgnome-time-slider and install the existing zfs-auto-snapshot
packages instead.

Comments/questions welcome ;)

Cheers,
Niall.

_______________________________________________
zfs-auto-snapshot mailing list
zfs-auto-snapshot at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot

I don''t have any problem with a rewrite, but please allow a
non-GUI-dependent solution for headless servers.  Also please add rsync as an
option, rather than replacing zfs send/recv.   Thanks.
-- 
This message posted from opensolaris.org

I welcome the re-write.  The deficiencies of the current snapshot cleanup
implementation have been a source of constant background irritation to me for a
while, and the subject of a few bugs.

Regarding the issues in contention

 - the send hooks capability is useful and should remain, but the implementation
of it may and probably should be vastly different.   I don''t think
it''s a terrible thing if the capability remains, even if it requires
some adjustment in the implementation of scripts people have written to make
them work in the new world.  That blurs the line a little in terms of interface
commitment.
 - I really would like better separation between gui and service, in particular
the dependency on a whole garden full of gnomes and X libs.   I don''t
want these on my cut down storage appliance.

In general:

It seems there''s scope and opportunity to separate the taking and
removing of snapshots by the service from other actions that may be triggered
(send, etc).   I don''t think you want those hooks executing in the
context or process of the service, for a number of reasons.  Wouldn''t
it be better to have some events published on the creation and deletion of
snapshots, and a separate service that can listen to those events and trigger
hooks and actions (eg. replication, including the established interface)
accordingly?  In general, why should my snapshot replication mechanism
specifically be limited to snapshots triggered by the auto-snapshot svc?

I''m also concerned about the sleep interval of the service, which as
described sleeps until the next scheduled snapshot.  This is all very well in
general, except that if I disable some of the shorter-period snapshots (say,
only daily and above) I only get daily checks against the space threshold.  Room
for improvement here.

Would there be a way to avoid taking snapshots if they''re going to be
zero-sized?  There''s a whole separate set of discussion about whether
deleting the 0-size snapshots is a good idea or not, entangled with some of the
current implementation issues.  However, to avoid unnecessary disk access (power
save spin-ups) it would be nice to avoid making snapshots and then deleting them
again straight after (and calling hooks on them :-).  This probably needs a zfs
change for a "discretionary snapshot" only if the fs has changed since
the previous one.

The rsync project will be a whole separate design effort.  It would be nice for
this to consider both "backing up zfs snapshots via rsync to remote
<other storage>" as well as "backing up remote <other
storage> to zfs with snaphots", notionally similar to rsnapshot and
other similar implementations.

--
Dan.

(posted here, rather than in response to the mailing list reference given,
because I''m not subscribed and because I never knew that mailing list
existed since it''s apparently not visible as a web forum).
-- 
This message posted from opensolaris.org

Daniel Carosone <dan at geek.com.au> writes:
> Would there be a way to avoid taking snapshots if they''re going to
be
> zero-sized?
I don''t think it is easy to do, the txg counter is on a pool level,
AFAIK:

  # zdb -u spool
  Uberblock

        magic = 0000000000bab10c
        version = 13
        txg = 1773324
        guid_sum = 16611641539891595281
        timestamp = 1258992244 UTC = Mon Nov 23 17:04:04 2009

it would help when the entire pool is idle, though.
> (posted here, rather than in response to the mailing list reference
> given, because I''m not subscribed [...]
ditto.

-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game

> Daniel Carosone <dan at geek.com.au> writes:
> 
> > Would there be a way to avoid taking snapshots if
> > they''re going to be zero-sized?
> 
> I don''t think it is easy to do, the txg counter is on
> a pool level,
> [..]
> it would help when the entire pool is idle, though.
.. which is exactly the scenario in question: when the disks are likely to be
spun down already (or to spin down soon without further activity), and you want
to avoid waking them up (or keeping them awake) with useless snapshot activity.

However, this highlights that a (pool? fs?) property that exposes the current
txg id (frozen in snapshots, as normal, if an fs property) might be enough for
the userspace daemon to make its own decision to avoid requesting snapshots,
without needing a whole discretionary mechanism in zfs itself.
-- 
This message posted from opensolaris.org

Kjetil Torgrim Homme wrote:
> Daniel Carosone <dan at geek.com.au> writes:
> 
>> Would there be a way to avoid taking snapshots if they''re
going to be
>> zero-sized?
> 
> I don''t think it is easy to do, the txg counter is on a pool
level,
> AFAIK:
> 
>   # zdb -u spool
>   Uberblock
> 
>         magic = 0000000000bab10c
>         version = 13
>         txg = 1773324
>         guid_sum = 16611641539891595281
>         timestamp = 1258992244 UTC = Mon Nov 23 17:04:04 2009
> 
> it would help when the entire pool is idle, though.
> 
>> (posted here, rather than in response to the mailing list reference
>> given, because I''m not subscribed [...]
> 
> ditto.
> 
I think I can see from this which filesystems have and have not changed 
since the last snapshot (@20091122 in this case)...

a20$ zfs list -t snapshot | grep 20091122
export/data at 20091122                499K      -   227G  -
export/home at 20091122                144K      -  15.6G  -
export/music at 20091122                  0      -  66.5G  -
export/virtualbox at 20091122             0      -   484K  -
export/virtualbox/OS0906 at 20091122      0      -  3.52G  -
export/virtualbox/xp at 20091122          0      -  12.1G  -
export/zones at 20091122                  0      -  22.5K  -
export/zones/s10 at 20091122              0      -  5.21G  -
a20$

All the ones with USED = 0 haven''t changed. Don''t know if this
info is
available without spinning up disks though.

-- 
Andrew Gabriel

Andrew Gabriel wrote:
> Kjetil Torgrim Homme wrote:
>> Daniel Carosone <dan at geek.com.au> writes:
>>
>>> Would there be a way to avoid taking snapshots if they''re
going to be
>>> zero-sized?
>>
>> I don''t think it is easy to do, the txg counter is on a pool
level,
>> AFAIK:
>>
>>   # zdb -u spool
>>   Uberblock
>>
>>         magic = 0000000000bab10c
>>         version = 13
>>         txg = 1773324
>>         guid_sum = 16611641539891595281
>>         timestamp = 1258992244 UTC = Mon Nov 23 17:04:04 2009
>>
>> it would help when the entire pool is idle, though.
>>
>>> (posted here, rather than in response to the mailing list reference
>>> given, because I''m not subscribed [...]
>>
>> ditto.
>>
> 
> I think I can see from this which filesystems have and have not changed 
> since the last snapshot (@20091122 in this case)...
> 
> a20$ zfs list -t snapshot | grep 20091122
> export/data at 20091122                499K      -   227G  -
> export/home at 20091122                144K      -  15.6G  -
> export/music at 20091122                  0      -  66.5G  -
> export/virtualbox at 20091122             0      -   484K  -
> export/virtualbox/OS0906 at 20091122      0      -  3.52G  -
> export/virtualbox/xp at 20091122          0      -  12.1G  -
> export/zones at 20091122                  0      -  22.5K  -
> export/zones/s10 at 20091122              0      -  5.21G  -
> a20$
> 
> All the ones with USED = 0 haven''t changed.
That is not the case.  A snapshot''s USED is zero if it has no unique
space,
ie if everything it references is also referenced by something else.  For 
example, the previous snapshot.

--matt

Daniel Carosone <dan at geek.com.au> writes:
>> I don''t think it is easy to do, the txg counter is on
>> a pool level,
>> [..]
>> it would help when the entire pool is idle, though.
>
> .. which is exactly the scenario in question: when the disks are
> likely to be spun down already (or to spin down soon without further
> activity), and you want to avoid waking them up (or keeping them
> awake) with useless snapshot activity.
good point!
> However, this highlights that a (pool? fs?) property that exposes the
> current txg id (frozen in snapshots, as normal, if an fs property)
> might be enough for the userspace daemon to make its own decision to
> avoid requesting snapshots, without needing a whole discretionary
> mechanism in zfs itself.
you can fetch the "cr_txg" (cr for creation) for a snapshot using zdb,
but the very creation of a snapshot requires a new txg to note that fact
in the pool.  if there are several filesystems to snapshot, you''ll get
a
sequence of cr_txg, and they won''t be adjacent.

  # zdb tank/test1 at snap1
  Dataset tank/test1 at snap1 [ZVOL], ID 78, cr_txg 872401, 4.03G, 3 objects
  # zdb -u tank
          txg = 872402
          timestamp = 1259064201 UTC = Tue Nov 24 13:03:21 2009
  # sync
  # zdb -u tank
          txg = 872402
  # zfs snapshot tank/test2 at snap1
  # zdb tank/test2 at snap1
  Dataset tank/test2 at snap1 [ZVOL], ID 80, cr_txg 872419, 4.03G, 3 objects
  # zdb -u tank
          txg = 872420
          timestamp = 1259064641 UTC = Tue Nov 24 13:10:41 2009

if the snapshot is taken recursively, all snapshots will have the same
cr_txg, but that requires the same configuration for all filesets.

-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game

> you can fetch the "cr_txg" (cr for creation) for a
> snapshot using zdb,
yes, but this is hardly an appropriate interface. zdb is also likely to cause
disk activity because it looks at many things other than the specific item in
question.
> but the very creation of a snapshot requires a new
> txg to note that fact in the pool.
yes, which is exactly what we''re trying to avoid, because it requires
disk activity to write.
> if the snapshot is taken recursively, all snapshots
> will have the same cr_txg, but that requires the
> same configuration for all filesets.
again, yes, but that''s irrelevant - the important knowledge at this
moment is that the txg has not changed since last time, and that thus there will
be no benefit in taking further snapshots, regardless of configuration.
-- 
This message posted from opensolaris.org

Daniel Carosone <dan at geek.com.au> writes:
>> you can fetch the "cr_txg" (cr for creation) for a
>> snapshot using zdb,
>
> yes, but this is hardly an appropriate interface.
agreed.
> zdb is also likely to cause disk activity because it looks at many
> things other than the specific item in question.
I''d expect meta-information like this to fit comfortably in RAM over
extended amounts of time.  haven''t tried, though.
>> but the very creation of a snapshot requires a new
>> txg to note that fact in the pool.
>
> yes, which is exactly what we''re trying to avoid, because it
requires
> disk activity to write.
you missed my point: you can''t compare the current txg to an old cr_txg
directly, since the current txg value will be at least 1 higher, even if
no changes have been made.
>> if the snapshot is taken recursively, all snapshots will have the
>> same cr_txg, but that requires the same configuration for all
>> filesets.
>
> again, yes, but that''s irrelevant - the important knowledge at
this
> moment is that the txg has not changed since last time, and that thus
> there will be no benefit in taking further snapshots, regardless of
> configuration.
yes, that''s what we''re trying to establish, and it''s
easier when
all snapshots are commited in the same txg.
-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game

> you missed my point: you can''t compare the current
> txg to an old cr_txg directly, since the current
> txg value will be at least 1 higher, even if
> no changes have been made.
OIC. So we also need a "txg dirty" or similar property to be exposed
from the kernel.
-- 
This message posted from opensolaris.org

> So we also need a "txg dirty" or similar
> property to be exposed from the kernel.
Or not..

if you find this condition, defer, but check again in a minute (really, after a
full txg_interval has passed) rather than on the next scheduled snapshot.

on that next check, if the txg has advanced again, snapshot.  if not, defer
until the next scheduled snapshot as usual.  Yes, the txg may now be dirty this
second time around - but it''s after the snapshot was due, so these
writes will be collected in the next snapshot.
-- 
This message posted from opensolaris.org