Daniel Carosone <d...@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/te...@snap1
  Dataset tank/te...@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/te...@snap1
  # zdb tank/te...@snap1
  Dataset tank/te...@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

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to