On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann <mar...@freebsduser.eu> wrote: > Whenever I modify zfs pools or filesystems it's possible to destroy [on a > bad day :-)] my data. A new > property "protected=on|off" in the pool and/or filesystem can help the > administrator for datalost > (e.g. "zpool destroy tank" or "zfs destroy <tank/filesystem>" command will > be rejected > when "protected=on" property is set). > > It's anywhere here on this list their can discuss/forward this feature > request? I hope you have > understand my post ;-)
I like the idea and it is likely not very hard to implement. This is very similar to how snapshot holds work. # zpool upgrade -v | grep -i hold 18 Snapshot user holds So long as you aren't using a really ancient zpool version, you could use this feature to protect your file systems. # zfs create a/b # zfs snapshot a/b@snap # zfs hold protectme a/b@snap # zfs destroy a/b cannot destroy 'a/b': filesystem has children use '-r' to destroy the following datasets: a/b@snap # zfs destroy -r a/b cannot destroy 'a/b@snap': snapshot is busy Of course, snapshots aren't free if you write to the file system. A way around that is to create an empty file system within the one that you are trying to protect. # zfs create a/1 # zfs create a/1/hold # zfs snapshot a/1/hold@hold # zfs hold 'saveme!' a/1/hold@hold # zfs holds a/1/hold@hold NAME TAG TIMESTAMP a/1/hold@hold saveme! Wed Feb 20 15:06:29 2013 # zfs destroy -r a/1 cannot destroy 'a/1/hold@hold': snapshot is busy Extending the hold mechanism to filesystems and volumes would be quite nice. Mike _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
