I would really add : make insane zfs destroy <-r|> poolname as harmless as
zpool destroy poolname (recoverable)
zfs destroy <-r|> poolname<|/filesystem>
this should behave like that:
o snapshot the filesystem to be deleted (each, name it
@deletedby_operatorname_date)
o hide the snapshot as long as the pool has enough space and
property snapshotbeforedelete=on (default off) is set 'on'
o free space by removing those snapshots no earlier then configured
in a inheritable pool/filesystem property snapshotbeforedeleteremoval=3days
(=0 preserve forever, 30min preserve for 30 minutes, ...)
o prevent deletion of a pool or filesystem if at least one
snapshot from the above save actions exists down the tree
o purging of snapshots would be done by
To be honest, I don't want a discussion like the "rm -rf" is one.
In front of the keyboard or inside scripts we are all humans with
all theyr mistakes. In opposite to the rm -rf, the ZFS Design
should take this extension without major changes. It should be
a generic rule of dump to implement safety if it is possible
at resonable low cost.
I think the full range of users, Enterprise to Home will appreciate
that theyr multi-million-$$-business/home_data does not go down
accidentially with the interactive=on (Bryan) or the the idea
written here. This in case someone makes an error and all the
data could still be there (!)...ZFS should protect the user as well
and not only look at the hardware redundancy.
Thomas
PS: think of the day where simple operator $NAME makes a typo
zfs destroy -r poolname and all the data still sits on the
disk. But no one is able to bring that valueable data back,
except restoration from tape with hours of downtime.
Sorry for repeating that, it hurts so much to not having
this feature.
On Sat, Feb 28, 2009 at 04:35:05AM -0500, Bryan Allen wrote:
> I for one would like an "interactive" attribute for zpools and
> filesystems, specifically for destroy.
>
> The existing behavior (no prompt) could be the default, but all
> filesystems would inherit from the zpool's attrib. so I'd only
> need to set interactive=on for the pool itself, not for each
> filesystem.
>
> I have yet (in almost two years of using ZFS) to bone myself by
> accidentally destroying tank/worthmorethanyourjob, but it's only
> a matter of time, regardless of how careful I am.
>
> The argument rm vs zfs destroy doesn't hold much water to me. I
> don't use rm -i, but destroying a single file or a hierarchy of
> directories is somewhat different than destroying a filesytem or
> entire pool. At least to my mind.
>
> As such, consider it a piece of mind feature.
> --
> bda
> Cyberpunk is dead. Long live cyberpunk.
> http://mirrorshades.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
--
Thomas Wagner
+49-171-6135989 http://www.wagner-net.net
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
