2012-01-13 7:26, Steve Gonczi wrote:

Any modified block (in absence of a snaphot) gets re-written
to a new location and the original block is freed.

So the earlier state you want to go back and snapshot is no longer there,

The essence of taking a snapshot is keeping the original blocks
instead of freeing them.

Perhaps I need to specify some usecases more clearly:

1) Snapshot added in-between existing snapshots, or even
   before the first one currently existing, i.e. just to
   facilitate incremental snapshot sends in small chunks
   over lousy media (where zfs send is likely to never
   succeed for huge datasets sent as one initial stream).

2) Cloning and/or rollback of a dataset at some point in
   time (TXG number) of which I forgot to add a timely
   snapshot of. Apparently, this would only work to ignore
   added data, since overwritten blocks would be lost.

   Exception: there is a "last" chance to reference last
   32-128 TXGs, uberblocks for which still exist in the
   ring. Say, 128*5sec = 640 sec > 10.5 min of rollback
   info guaranteed to be not overwritten by ZFS COW.
   This would compensate most of those "Oh sh*t what
   have I done!?" moments of operator/admin errors,
   typos, etc. Injecting a snapshot into "3 minutes ago"
   would help retain that data not-actually-deleted
   from disk while you go about repairing damage ;)

   Perhaps this would even allow for undeletion of datasets
   which you never intended to destroy (notably, I had
   LU BE deletion trying to kill off my zone datasets
   some time around snv_101 or so; they were only saved
   by being mounted and running at the time).

3) Use along with that proposed replacement of existing
   snapshots (with degraded unreadable blocks) while
   maintaining the rest of snapshot/clone tree. If this
   "technology" were to be implemented, injected snaps
   could naturally be used to "fence off" the corrupted
   area (TXG number range) and replace the resulting
   smaller corrupt snapshot with good data from another

   I hope it is not theoretically impossible to write
   this replacement snapshot in such a manner that the
   resulting sequence of block histories would still
   make sense as valid files. This block reallocation
   is not much different from autorepairs on resilver
   or scrub... I think :)

zfs-discuss mailing list

Reply via email to