2012-01-13 7:26, Steve Gonczi wrote:
JIm,
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
storage.
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 :)
Thanks,
//Jim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
