On Mon, Jan 13, 2014 at 1:07 AM, Andriy Gapon <[email protected]> wrote:
> > 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... > > Mounting the fs read-only, or using recv -F, seem like straightforward ways of expressing the admin's intent. There are lots of other ways to "inadvertently" cause modifications to a filesystem (e.g. atime). Maybe we can make it easier to do the right thing (e.g. flag to zfs recv that sets the readonly property?) I could see making the delete queue transparent to the user by basically delaying processing it until some other modification happens on the fs. That way the filesystem doesn't diverge solely as a result of the delete queue. --matt
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
