]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit - contrib/unbound/libunbound/python/doc/conf.py
MFV r329718: 8520 7198 lzc_rollback_to should support rolling back to origin
authorAndriy Gapon <avg@FreeBSD.org>
Wed, 21 Feb 2018 15:12:14 +0000 (15:12 +0000)
committerAndriy Gapon <avg@FreeBSD.org>
Wed, 21 Feb 2018 15:12:14 +0000 (15:12 +0000)
commitcfb675a1384867c4c69b8410afefa27070bcfc50
tree1bf4f9992e44ac0fedbb13220ea6cc71412ceb95
parent754d27df02e5026bf604b716f53b4059dae09837
parent86b66fca8b87d5666cea41e33950bf1768d13ff3
MFV r329718: 8520 7198 lzc_rollback_to should support rolling back to origin

illumos/illumos-gate@95643f75d23914a3e332adc9661ed51749e9858d
https://github.com/illumos/illumos-gate/commit/95643f75d23914a3e332adc9661ed51749e9858d

https://www.illumos.org/issues/8520
  lzc_rollback_to() should support rolling back to a clone's origin.
  The current checks in zfs_ioc_rollback() would not allow that because the
  origin snapshot belongs to a different filesystem.
  The overly restrictive check was introduced in 7600, but it was not a
  regression as none of the existing tools provided a way to rollback to the
  origin.

https://www.illumos.org/issues/7198
  EINVAL is returned when a dataset does not have any snapshots, so there is
  nothing to roll back to.
  Although the code in zfs_do_rollback checks for that condition in advance, it's
  still possible that the snapshot(s) gets removed after the check and before the
  rollback sync task is executed.
  At the moment zfs command would crash when that happens.

Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Author: Andriy Gapon <avg@FreeBSD.org>
MFC after: 2 weeks
cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c