On Tue, May 09, 2006 at 04:56:05PM -0500, Al Hopper wrote: > While I agree that zfs send is incredibly useful, after reading this post > I'm asking myself: > > a) This already sounds like we're descending the slippery slope of > 'checkpointing' - which is an incredibly hard problem to solve and [...]
This is replication, not checkpointing. > b) You can never sucessfully checkpoint an application via data > replication. Why? Because, at some point you're trying to take a > snapshot of a process (or related processes) that modifies multiple files > that represent inter-related data. That is what we have relational > databases for and the concept of: But if zfs send/receive can also send snapshots, that is, if I create a snapshot on a filesystem under replication the same snapshot should show up at the replica, then we place the checkpointing burden on the application/administrator. > The real issue is where do you draw the line? I think live replication could be incredibly useful, lags and all, because not everything you might replicate involves complex state, much that does supports journalling/rollback anyways, and you can do your own snapshotting to deal with checkpointing, in which case live replication merely spreads the cost of replication around, instead of making it bursty (but may be less efficient since some of the churn will be redundant). > And how do you manage user expectations if the user is convinced that by > mirroring the active filesystem, they have achieved site > diversity/failover? How is remote replication in this regard different from local mirroring? Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
