On Mon, Apr 27, 2015 at 5:23 AM, Andriy Gapon <andriy.ga...@clusterhq.com> wrote:
> > Perhaps the following would be an unintended, unorthodox use of zfs send + > recv, > but I do not immediately see why it shouldn't work (which it doesn't). > Let's assume that we have filesystem fs1 with 2 snapshots, fs1@fromsnap > and > fs@bp. Let's then clone fs@bp to fs2 and then later make another snapshot > fs2@tosnap. After that we produce a full send stream for fs1@fromsnap and > receive it to a new filesystem dest as dest@fromsnap. Finally, we > produce an > incremental stream fs1@fromsnap -> fs2@tosnap and receive to dest as > dest@tosnap. > > My expectation is that the above should succeed and we should get dest > filesystem equivalent to fs2@tosnap. After all, if we produced a full > stream > for fs2@tosnap and received it to dest2, then that operation would > succeed. > > But, as far as I can see, the current code insists that an incremental > stream > that crossed a branch point on the sending side (that is, its start > snapshot is > in one filesystem and its end snapshot is in the filesystem's clone) must > create > a new filesystem (a clone) on the receiving side as well. > > I wonder where that requirement comes from. > What could go wrong if we allowed the incremental stream with the clone > flag to > be received into an existing filesystem (provided that all other things > matched) ? > > Sounds good to me, that should be able to work. In principle, the clone flag (as well as the name) in the send stream should be advisory, and the receiving system should be able to construct any valid tree of snapshots. --matt
_______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer
