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