This is probably a well known issue, but I wonder if anything smart and not overly elaborate can be done about it. If we generate a stream from a live filesystem, then it is possible that the delete queue object in it would be non-empty. When such a stream is received and a replicated filesystem is mounted read/write, then it would diverge from the original because of delete queue processing. And thus it would be impossible to receive subsequent incremental streams unless a rollback is done first. So, the workarounds are obvious: - unmount the original filesystem before zfs send - never mount the replicated filesystem read-write - always do rollback before a subsequent incremental receive
But I wonder if we could make this scenario completely transparent to an end user... Thanks! -- Andriy Gapon
_______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer
