Project

General

Profile

Bug #5150

zfs clone of a defer_destroy snapshot causes strangeness

Added by Matthew Ahrens about 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Matthew Ahrens
Category:
zfs - Zettabyte File System
Start date:
2014-09-11
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

When a clone is created of a snapshot that has been marked for deferred destroy
(with "zfs destroy -d"), the clone "inherits" the defer_destroy flag from the
origin, and any snapshots of the clone "inherit" the defer_destroy flag from
the clone. This causes a strange situation where the clone's snapshots are
marked for defer_destroy but they have no holds or clones. If the clone's
snapshot gets a hold or clone, which is then deleted, we will honor the
incorrectly-set defer_destroy flag and delete the snapshot!

steps to reproduce:

zpool create test c1t1d0
zfs create test/fs
zfs snapshot test/fs@a
zfs clone test/fs@a test/clone
zfs destroy -d test/fs@a
zfs clone test/fs@a test/clone2
zfs snapshot test/clone2@a
zfs hold hld test/clone2@a
zfs release hld test/clone2@a
zfs list -r -t all test

<test/clone2@a has been destroyed>

We noticed that this causes dcenter to get very confused, because it treats
snapshots that are marked defer_destroy as not existing. So it won't see any
snapshots of the clone that's marked defer_destroy.

History

#1

Updated by Electric Monk about 5 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

git commit 42fcb65ea4f2c6f8cc5a3c6142a486cb49871fd2

commit  42fcb65ea4f2c6f8cc5a3c6142a486cb49871fd2
Author: Matthew Ahrens <mahrens@delphix.com>
Date:   2014-09-19T04:08:23.000Z

    5150 zfs clone of a defer_destroy snapshot causes strangeness
    Reviewed by: Christopher Siden <christopher.siden@delphix.com>
    Reviewed by: George Wilson <george.wilson@delphix.com>
    Reviewed by: Max Grossman <max.grossman@delphix.com>
    Reviewed by: Saso Kiselkov <skiselkov.ml@gmail.com>
    Reviewed by: Richard Elling <richard.elling@gmail.com>
    Approved by: Robert Mustacchi <rm@joyent.com>

Also available in: Atom PDF