zfs discuss - Jul 2006 - Feature proposal: trashcan via auto-snapshot with every txg commit

Do an automatic pool snapshot (using the recursive atomic snapshot feature that
Matt Ahrens implemented recently, taking time proportional to the number of
filesystems in the pool) upon every txg commit.

Management of the trashcan snapshots could be done by some user-configurable
policy such as preserving only a certain number of trashcan shapshots, or only
the ones younger than a specified age, or destroying old ones at a sufficient
rate to maintain the trashcan snapshots'' total disk space usage within
some specified quota (or to maintain pool free space above some specified
minimum), etc.

But this would provide an effective cure for the all-to-common mistakes of
running "rm *" in the wrong directory or overwriting the wrong file
and realizing the mistake just a moment after you''ve pressed
"enter", among other examples.

Even if this pool-wide feature would be undesirable on a particular pool due to
performance concerns, it could still be applied on a filesystem basis. For
example, /home might be a good candidate.

A desire has been mentioned elsewhere in this forum for a snapshot-on-write
feature, to which a response was made that auto-snapshotting for every byte
written to every file would be really slow, to which a response was made that
auto-snapshotting upon file closure might be an adequate substitute. But the
latter isn''t an adequate substitute in some important cases. Providing
auto-snapshot on every txg commit would be an efficient compromise.

Also, combining the trashcan snapshot feature (with the management policy set to
never delete old snapshots) with the differential pool feature I mentioned today
in another message (with the differential pool located on physically secure
media) would provide an excellent auditing tool.
 
 
This message posted from opensolaris.org

On Tue, Jul 25, 2006 at 11:23:21PM -0700, Andrew wrote:
> Do an automatic pool snapshot (using the recursive atomic snapshot
> feature that Matt Ahrens implemented recently, taking time
> proportional to the number of filesystems in the pool) upon every txg
> commit.
This is a good idea, one that we''ve had in the back of our minds for a
long time, but apparently never put into a bug report.  I''ve filed RFE
6453726 "want snapshot every txg".

As a workaround, you could write a script to simply take a snapshot
every N seconds.  It could clean out snapshots that are not different
from their neighbors (although this may be difficult to determine with
100% reliability), and old snapshots that are using too much space.

--matt