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) ? -- Andriy Gapon _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
