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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
