On Thu, Jan 15, 2015 at 6:46 AM, Wido den Hollander <wido@xxxxxxxx> wrote: > Hi, > > Although the userland tools like 'ceph' and 'rados' have a safeguard > against fat fingers when it comes to removing a pool there is no such > safeguard when using native librados. > > The danger still exists that by accident you remove a pool which is then > completely gone, no way to restore it. > > This is still something I find quite dangerous, so I was thinking about > a additional 'Immutable bit' which could be set on a pool before > rados_pool_delete() allows this pool to be removed. > > Is it a sane thing to look at 'features' which pools could have? Other > features which might be set on a pool: > > - Read Only (all write operations return -EPERM) > - Delete Protected > > It's just that looking at a 20TB RBD pool and thinking that just one API > call could remove this pool make me a bit scared. > > Am I the only one or is this something worth looking in to? I completely agree. A while back I opened an issue for that, #9792, with some suggestions: - require a special key for this command - pool removal doesn't apply immediately, but rather first switches pool to 'pending removal' - pending removal state reflected in the cluster status - operation can be cancelled when pending Yehuda -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
